A Practical Look at Modern Example-Based Development
I've seen enough teams try to implement examples-first workflows without really understanding what they were getting into. The term Examples Modern gets thrown around a lot in agile circles, but most people use it loosely. Here's how it actually works in practice. The core idea is straightforward: instead of writing requirements documents that developers interpret, you define concrete input-output pairs that specify exactly what the system should do. This is different from unit tests in that the examples are meant to be read by stakeholders, not just executed by machines. You're creating a shared language between product, engineering, and QA before any code ships.
How to Build an Examples Modern Workflow
Start by picking a format. Gherkin is the most common because it's readable, but plain JSON or YAML tables work better when your stakeholders aren't technical. I found that markdown tables with explicit column headers actually reduced miscommunication more than Gherkin's Given-When-Then structure for our team. The syntax matters less than the discipline of requiring every feature to have at least three examples: one happy path, one edge case, and one failure mode. Here's the part nobody tells you: the examples have to live in the same place as the code. When I moved our example files from a Confluence page into the repository alongside the feature branches, review quality improved noticeably because developers couldn't ignore ambiguous examples anymore. Stakeholders also started catching gaps during PR reviews that would have surfaced weeks later in UAT.
Examples Modern in Practice
Consider a payment processing feature. A minimal set of examples might look like this: Example 1: Valid card, sufficient funds transaction approved, receipt generated within 2 seconds. Example 2: Valid card, insufficient funds transaction declined, specific error code returned, no receipt.
Get the Full Details
Example 3: Expired card transaction declined, user shown renewal prompt, no charge attempted. That's it. Three rows. Before I saw this done properly, I watched a team write a forty-page requirements doc for the same feature and still miss the expired card scenario entirely. The examples force you to confront edge cases instead of letting them hide in prose. The real work comes after writing them. You need tooling that can parse these examples and either generate stub tests or validate implementations against them. Cucumber, SpecFlow, and custom runners all handle this, but the tool choice is secondary to having a pipeline that fails the build when examples drift from the code.
Where It Breaks Down
Examples Modern doesn't work for exploratory features where the behavior isn't known yet. If you're building something genuinely new and you can't predict the input-output pairs, forcing examples just creates false confidence. I learned this the hard way when we tried to apply the method to a recommendation algorithm that was still being researched. We spent two weeks writing examples for behavior that didn't exist, then threw them all away when the model architecture changed. It also requires a cultural shift. Product managers resist because writing concrete examples is harder than writing vague wishes. Developers resist because they've been burned by brittle test suites before. The teams that make it work treat examples as living documents, not contracts. You update them constantly, and you expect to update them constantly. The best I've seen combine examples with property-based testing. The examples cover the business-critical paths that matter to stakeholders, while property-based tests catch the edge cases nobody thought to write down. This hybrid approach took some getting used to, but it's been the most reliable setup I've worked with.
If you want to try this, start small. Pick one feature in your next sprint and write five examples instead of one requirements paragraph. See what gaps appear. The process itself is usually more valuable than the output.
