How Specification by Example can help to get better at what to do
Capability building is more then passing on knowledge; it’s about experiential learning—applying concepts in real-world scenarios while balancing AI-saturated efficiency with human sense making.
This blog series delves deeper into the intersection of technology and human development, highlighting how you can build your resilient adaptiveness to thrive in the digital age.
I like to share what just inspired me from a recent TTA talk.
As I benefit from the leaps of insights from Rich Allen & Jacob Duijzer, here’s what I took away from this.
When people and teams are focused on delivering value, it’s easy to just concentrate on getting things done. But there's something just as important—learning how to understand customer needs and building the skills to deliver better results over time.
That’s where Specification by Example (SBE) can really help.
SBE is more than just a way to write better requirements. It helps individuals and teams grow, improve how they work, and get better at delivering meaningful results. In this article, we’ll look at what it is and how it supports real learning and capability building.
What Is Specification by Example?
Specification by Example is a way to describe what a product or system should do, using real examples. Instead of writing vague descriptions or complicated documents, people from different roles come together and write clear, real-life examples of how something should work.
For example, instead of saying, “The system should apply discounts,” the team might say:
“If a customer buys 3 or more items, they get 10% off the total price.”
These examples are created through conversations with business experts, developers, testers, designers—anyone involved. Later, they’re often turned into automated checks, so you always know the product still works as expected.
Why It Helps People and Teams Grow
Specification by Example helps people and teams learn, improve how they collaborate, and become better at solving the right problems. Here's how:
1. Everyone Understands What’s Really Needed
SBE encourages conversations. Instead of working in silos or making assumptions, people work together to understand what’s needed—and they use real-world examples to make sure it’s clear.
This builds shared understanding and helps avoid confusion or rework later.
2. You Learn While You Work
Talking through examples, clarifying edge cases, and testing your ideas with examples help you learn as you go. You discover gaps in thinking early, get feedback quickly, and adapt based on what you learn.
It turns daily work into a learning experience.
3. You Start Thinking Like a Customer
Real examples reflect real customer situations. So when you work this way, you start thinking more about how your users experience things. You spot problems before they happen and come up with better solutions—because you’re thinking from the customer’s point of view.
Helpful Habits That Build Capability
SBE isn’t just a method—it encourages good habits that help you grow over time:
✔ Start With the “Why”
Before jumping into building or solving, you ask: What problem are we solving? This keeps everyone focused on value and purpose, not just ticking off tasks.
✔ Collaborate Early
Creating examples together helps you align before work begins. It builds trust, encourages better teamwork, and makes sure everyone contributes to the solution.
✔ Use Real-Life Examples
Concrete examples make complex ideas easier to understand. If you can’t describe what you want with a real example, the idea probably isn’t clear enough yet.
✔ Test Automatically When You Can
Turning examples into automated checks helps you catch mistakes early and know quickly when something breaks. It also saves time in the long run.
✔ Keep the Documentation Alive
Because the examples stay connected to the system and get updated when things change, they become living documentation—easy to refer to and useful for teaching new people.
It Also Builds a Learning Culture
When you work this way, it naturally creates a team or work culture that supports learning:
People ask more questions
There’s space for different viewpoints
Everyone can contribute to understanding and improving the work
That’s powerful. It creates an environment where people feel safe, supported, and ready to grow.
What You’ll Notice Over Time
Teams and individuals who use Specification by Example often experience:
Fewer misunderstandings or mistakes
Clearer conversations about customer needs
Faster delivery, because you get things right sooner
Easier onboarding for new team members or partners
Most importantly, you become more adaptable—ready to handle change and keep getting better.
It Benefits the Whole Organization
SBE isn’t just for developers or technical teams. It helps everyone who’s involved in delivering value—product managers, designers, support staff, marketing, operations, and leadership.
It leads to:
Better decisions
Stronger alignment across roles
More confidence that the work being done is the right work
As more people across a company start working this way, it supports bigger shifts—like improving how you scale, how you respond to change, and how you link daily work to long-term goals.
Mostly SBE is used in high performant agile delivery teams in software product deveopment context.
A parallel approach I found very applicable also outside tech is User Needs Mapping.
What Is User Needs Mapping?
User needs mapping is a way to make the invisible… visible.
It helps individuals and teams understand what users are really trying to do, what gets in their way, and what matters most to them. It connects customer goals, pain points, and context to the work you're doing—so you're solving real problems, not just building features.
Think of it like putting yourself in the customer’s shoes and asking:
What are they trying to achieve?
What’s stopping them?
How can we help?
By making this thinking visual, shared, and structured, teams can align better and focus on delivering the right value.
A Simple Example
Let’s say you’re working on an online bookstore.
Instead of jumping straight to “Let’s build a recommendation engine,” you take a step back and explore user needs:
User Goal / Need Pain Point What Might Help Avid reader Discover books similar to what they like Overwhelmed by choice, can’t find good matches Show suggestions based on past purchases Busy parent Quickly find a gift for a child Doesn’t know what’s age-appropriate Filter by age and interests Student Find the cheapest version of a textbook High prices, confusing editions Compare prices and show edition summaries
This map helps you see the patterns, so you don’t just build what’s easy—you build what’s meaningful.
In a Team Setting
You can create user needs maps collaboratively in a workshop:
Start with a few user types (personas or real users).
Ask: “What are they trying to do?” and write one goal per sticky.
For each goal, ask: “What’s frustrating about that today?”
Then brainstorm: “How might we help?” or “What change would improve this?”
Use a simple wall, Miro board, or canvas like this:
[USER] → [GOAL] → [PAIN POINT] → [OPPORTUNITY]
This map becomes a guide to shape specifications, examples, and design conversations. More advanced evolution can look like
How It Connects to Specification by Example
When you do user needs mapping before or alongside Specification by Example, you:
Choose better examples (based on real needs)
Focus conversations on value, not just logic
Spot edge cases based on real-world frustration
Help everyone think like the user
So instead of just writing examples like:
“If the customer is logged in, show the discount.”
You get examples like:
“When a student logs in and searches for a textbook, they see used versions if available—because cost is their #1 concern.”
That’s needs-based thinking, and it leads to smarter work.
A very enlightening FFconference talk from last week gives a sweet illustration from the inventor Richard Allens angle. Tons of experience!
Final Thoughts
Specification by Example is a simple idea—use real examples to understand what’s needed and how it should work. But that small shift can create a big impact.
It helps people and teams become better at learning, solving problems, and creating real value for the customer.
If you’re looking for a practical way to build capability—start with examples.
They lead to better conversations, better outcomes, and better ways of working.
Next week Jacob Duijzer will elaborate in Eindhoven on the link between TeamTopologies and BDD, seems like a very interesting program.
Show your support
Every post on Socio-Technical Criteria takes days of research and 1 full day of (re)writing. You can show your support with small gestures, and that’s hugely appreciated!