Mastering the Start: Why Your Client's Wishlist Isn't Enough
The Wishlist Problem
Every client comes with a wishlist. Features they want. Functionality they've seen in competitors. Ideas that came up in a brainstorm. Things that seem obviously necessary but haven't been validated with real users.
The wishlist is the enemy of a good start.
Not because client input is bad — it's essential. But because a wishlist conflates wants with needs, features with outcomes, and solutions with problems. If you start building from a wishlist, you'll build a lot of things that don't matter and miss a few things that do.
What "Mastering the Start" Actually Means
Mastering the start means doing the discovery work that transforms a wishlist into a strategy. It requires asking uncomfortable questions:
What problem are we actually solving? Not the feature request, but the underlying user problem that the feature is supposed to address. These are often different things.
Who is the user, really? Not the personas in the brief, but the actual humans who will use this product. What do they currently do? What do they actually care about? What would make their day better?
What does success look like? Not "launch the feature," but what user behaviour change would tell you the feature is working? If you can't answer this before you build, you can't measure it after.
What's the smallest version of this that would tell us if we're right? Almost every feature can be made smaller. Finding the minimum useful version is where real product thinking starts.
The Cost of Getting It Wrong
The industry has good data on this: fixing a mistake in requirements costs 5-10x what it would have cost to get the requirement right. Fixing it in production costs 100x. The start is where the leverage is.
We've seen teams spend months building features that get removed before launch because nobody questioned whether they were the right features to build. We've seen products fail to find PMF because they were built around the wishlist of one opinionated stakeholder rather than the actual needs of real users.
The cost is always higher than it would have been to invest properly in the start.
What a Good Start Looks Like
A good start for a development engagement involves:
Discovery sprint — 1-2 weeks of user research, competitive analysis, and stakeholder interviews. The output is a clear problem statement, not a feature list.
Prioritisation framework — A structured way to evaluate what to build first based on user value, business impact, and technical feasibility. Not all features are created equal.
MVP scope — The smallest set of functionality that proves the core value proposition. Everything else is phase two.
Success metrics — Defined before a line of code is written. What are we measuring? What would tell us we got it right?
The Development Team's Role
Development teams are often passive recipients of requirements. The best ones aren't. The best development teams push back on wishlists, ask the uncomfortable questions, and help clients get to a strategy before they get to a spec.
This is harder in the short term. It creates friction. Clients sometimes push back on the discovery process because they "already know what they want."
But the development teams that master the start consistently deliver better products, on time, with fewer costly revisions. That's the long game worth playing.
