This is Part 1 of the From Discovery to Delivery series.
GreenBox is a small startup connecting local farms with subscribers who want weekly produce boxes. Fresh seasonal vegetables, delivered to your door, sourced from farms within thirty miles. Simple concept.
The team is five people. Maya founded it – she grew up on a farm and knows the supply side cold. Tom and Priya are the developers. Jas handles design and product. Sam does everything else: marketing, operations, the odd customer support email when they eventually get that far.
They have seed funding and about three months to prove the idea works. Maya has a clear picture of the business in her head. She describes it in the kickoff meeting: “Farms list what they have each week. Customers subscribe to a box size. We match supply to demand, pack the boxes, and deliver.”
Sounds straightforward. The team gets to work.
Week one
Tom starts building the subscription system. He picks the obvious model: customers choose a box size – small or large – enter payment details, and get charged weekly. He builds the signup flow, the Stripe integration, and a basic subscription data model.
Priya starts on the farm side. She builds a portal where farms can list their available produce: tomatoes, 50kg, £2/kg. She adds a simple inventory management screen.
Jas designs a beautiful customer experience. She mocks up a box customisation page where subscribers can pick which items they want each week. She’s thinking about the customer delight angle – let people choose exactly what goes in their box.
They’re moving fast. Code is shipping. Slack is buzzing with screenshots and pull requests. It feels productive.
Week two
Maya reviews what the team has built.
The subscription system looks reasonable, but Tom has assumed the box contents are fixed – the same items every week. “No,” Maya explains. “The whole point is that contents change based on what farms have available that week. Seasonal produce. That’s what makes it different from a supermarket delivery.”
Tom’s subscription model doesn’t account for variable contents at all. The data model is wrong. That’s a substantial rewrite.
Priya’s farm portal works, but she has questions nobody has answered. How far in advance do farms need to commit their availability? Can they update quantities after a deadline? What happens when total supply across all farms doesn’t cover all subscriber orders? She’s been guessing, and some of those guesses are wrong.
Jas’s customisation designs are beautiful. Maya looks at them and says, “Customers don’t pick items. We curate the box. That’s the value proposition – they trust us to give them good stuff, and they don’t have to think about it.”
The customisation flow is entirely wasted work.
Week three
The team tries to course correct. Tom starts rebuilding the subscription model to support variable weekly contents. Priya pauses the farm portal to wait for answers about supply commitment deadlines. Jas redesigns the customer experience without customisation, but now she’s unsure what the customer actually sees each week. A preview of what’s coming? A surprise? A notification after packing?
New questions keep surfacing:
- What happens when a customer is allergic to something in this week’s box?
- Do farms get paid per item, per box, or per week?
- Who decides substitutions when a farm can’t deliver what they promised?
- What about delivery logistics – own drivers or a courier?
- What if a customer wants to skip a week on holiday?
Three weeks in, the team has half a subscription system built on wrong assumptions, a farm portal that nobody’s sure how to finish, a discarded set of designs, and a growing list of questions that should have been answered before anyone opened an IDE.
They’re not lazy. They’re not bad at their jobs. They just started building before they understood the problem.
The expensive kind of learning
Every one of those surprises was knowable. Maya had the answers – or at least knew where the open questions were – but nobody thought to ask systematically. The team assumed they understood the domain because the concept sounded simple.
This is incredibly common. I’ve seen it in startups, in enterprise teams, in agencies. The more obvious a concept sounds, the more dangerous it is, because people skip discovery. “It’s just a…” is one of the most expensive phrases in software development.
The cost isn’t just the wasted code. It’s the trust erosion. Tom is frustrated because his work got thrown away. Jas is frustrated because nobody told her the customisation premise was wrong. Priya is blocked. Maya is wondering if she hired the right people. Everyone’s doing their best, but the team is pulling in different directions because they never built a shared understanding of what they’re actually building.
Slowing down to speed up
Maya’s friend Lee – who’s been through this before – asks a simple question over coffee: “Before you started building, did you all sit down and map out how the business actually works?”
The answer is no. Maya described it in a couple of sentences. The team heard what they expected to hear. Everyone filled in the gaps with their own assumptions.
Lee suggests they try a different approach. Instead of building and discovering problems in code reviews, they should invest a few days in structured discovery. Understand the domain together. Find the unknowns. Agree on priorities. Then build.
“You’ll feel like you’re going slower,” Lee says. “You’re not. You’re just putting the learning where it’s cheap – on sticky notes and whiteboards instead of in pull requests and production incidents.”
What’s next
Over the rest of this series, I’ll walk through the techniques the GreenBox team uses to turn things around:
- Event Storming: Building Shared Understanding (est. 30 March) — Getting the whole domain out of Maya's head and onto a wall, so everyone sees the same picture.
- Value Stream Mapping: Finding Where to Focus (est. 6 April) — Figuring out where value actually flows and where the team should focus first.
- Example Mapping: Making Stories Concrete (est. 13 April) — Turning vague stories into concrete, testable examples that developers can build from.
- Impact Mapping: Connecting Work to Goals (est. 20 April) — Connecting features to business goals so the team builds what matters, not just what's obvious.
- User Story Mapping: Seeing the Whole (est. 27 April) — Visualising the full user journey and slicing releases sensibly.
- When Workshops Go Wrong (est. 4 May) — What happens when discovery techniques don't go to plan, and how to handle it.
- From Stories to Working Software (est. 11 May) — Taking everything the team has learned and turning it into tested, working code -- with LLMs as implementation partners.
The tools themselves aren’t complicated. The hard part is knowing when to reach for which one, and having the discipline to do the thinking before you do the typing.
From Discovery to Delivery — a series on getting from vague idea to working software.
- The Wrong Kind of Fast (you are here)
- Event Storming: Building Shared Understanding (est. 30 March)
- Value Stream Mapping: Finding Where to Focus (est. 6 April)
- Example Mapping: Making Stories Concrete (est. 13 April)
- Impact Mapping: Connecting Work to Goals (est. 20 April)
- User Story Mapping: Seeing the Whole (est. 27 April)
- When Workshops Go Wrong (est. 4 May)
- From Stories to Working Software (est. 11 May)