The product development myths you should stop believing

It's easy to understand where this one comes from. When you're putting a new product in front of customers, you want people to have a good experience, so the instinct is to keep polishing until everything feels finished. The trouble is that "finished" can move further away every time you get close to it. A new feature gets added because it could make the product more useful, a few more edge cases are discovered, the onboarding could be improved, the design could be refined, and suddenly the original launch date has disappeared beneath a much larger scope.

The bigger issue is that you can only learn so much by looking at the product from inside your own team. You might have spent days debating the wording of a button, only to discover when someone uses the product that they don't understand the journey leading up to it. You might build an advanced feature because everyone agrees it will be useful, only to find that users rarely need it. You might assume a particular part of the experience is the biggest source of frustration when, in reality, people are getting stuck somewhere completely different.

None of those things are obvious until you put the product, or at least a realistic version of it, in front of the people who are going to use it.

That is where the idea of a minimum viable product becomes useful. An MVP isn't an excuse to release something unreliable or unfinished in the areas that matter. It is about identifying the smallest version of the product that can deliver the core value and give you meaningful feedback.

The UK Government's service guidance recommends using prototypes to explore and test ideas before committing to building them, because it gives teams a way to learn quickly without taking on the full cost of development. That principle applies to commercial products just as much as public services: if you can test an important assumption with a prototype, you have an opportunity to learn before you've spent the money to turn that assumption into production code.

So rather than asking whether the product is perfect, a more useful question is whether it is ready to teach you something. If the core problem is clear, the experience is usable, the product is technically sound enough for its intended audience and you have a clear idea of what you want to learn from real usage, you may be much closer to a valuable launch than you think.

Feature creep rarely arrives wearing a sign that says "this is a bad idea". Usually, it arrives as a perfectly reasonable suggestion. A customer has asked for something, the sales team has spotted an opportunity, someone internally thinks a particular feature would make the product more competitive, or the development team can see a relatively easy way to add another capability. Individually, those requests can all make sense. The problem comes when they accumulate without a clear sense of what the product actually needs to do exceptionally well.

More functionality can make a product more capable, but capability and usefulness aren't the same thing. Every additional feature introduces another decision for the user, another part of the interface they have to understand and another piece of functionality the team has to design, build, test, support and maintain. Research into feature fatigue has found that although people can initially be attracted to products with more capabilities, having too many features can ultimately make the experience feel more difficult and less appealing.

That is something product teams can easily overlook because, from the inside, every new feature feels like progress. A longer roadmap looks productive. A growing backlog can feel like evidence that the product is becoming more sophisticated. But users don't experience your roadmap. They experience the interface in front of them, and if that interface asks them to navigate through unnecessary options before they can accomplish the thing they actually came to do, more functionality can quickly become a disadvantage.

The better question is not "what else could we add?" but "what would make this experience more useful for the person trying to achieve their goal?" If you're building an app that helps someone manage their travel, for example, there may eventually be opportunities to add recommendations, booking functionality, social features, loyalty tools and plenty more.

But if the core experience of finding and managing a journey is confusing, adding another feature doesn't solve the underlying problem. Sometimes the most valuable thing you can do for a product is decide what doesn't belong in it yet.

Experience matters enormously in product development. If you've spent years in an industry and regularly speak to customers, you should absolutely bring that knowledge into the process.

The mistake is treating that knowledge as proof of what users will do with a new product. Knowing that customers have a problem is different from knowing exactly how they want that problem solved, and knowing what people say they want is different again from seeing what they actually use when a product is available to them.

This is particularly important when you're close to the product yourself. You know how it is supposed to work, you know the terminology, you understand the decisions behind the interface and you have probably discussed the same journeys many times. Your users don't have that context. Something that feels obvious to the team can be confusing to somebody seeing it for the first time, and that gap between what the team intended and what the user understood is where some of the most useful product insights come from.

GOV.UK's service guidance makes a similar point by encouraging teams to understand the problem before committing to a particular solution and to test assumptions early. That mindset is valuable because your original idea should be treated as a hypothesis rather than a fact.

You might be right about the problem, but wrong about the priority. You might be right about the priority, but wrong about the solution. You might even discover that the people you thought were the primary users aren't the people who get the most value from the product.

The sooner you can find those things out, the better. A short conversation with a customer, a prototype test, a clickable journey or a small release can all give you evidence that changes the direction of the product. That isn't undermining the original idea; it is making the idea stronger.

It's common for research to be treated as a phase that happens before the "real" work begins. You interview customers, gather insights, create your personas and requirements, and then move into design and development.

The trouble with that approach is that the product doesn't stop changing once discovery is over. As soon as you make something tangible, you create new questions, and those questions are often much more specific and useful than the ones you could answer when the product was still an idea.

A prototype can reveal that a journey is confusing. A first release can show that people are using a feature in a completely different way from what you expected. Analytics can highlight a drop-off point that nobody noticed during testing, while customer support conversations can reveal a recurring problem that isn't visible in the numbers. All of that is research, even if it doesn't look like the traditional research phase people imagine.

The GOV.UK Service Manual recommends carrying out smaller rounds of research throughout development rather than relying on one large research exercise at the beginning or end. That approach makes sense because it creates a much tighter feedback loop. You make a decision, test it, learn from it and adjust, rather than making dozens of decisions upfront and discovering much later that several of them were based on the same incorrect assumption.

You don't necessarily need hundreds of participants to do this either. The right number depends on what you're trying to learn, but for qualitative usability research, smaller groups can reveal repeated problems quickly.

The guidance recommends around four to eight participants for a round of research in many cases, while emphasising that the appropriate number depends on the method and research question. The important thing is not hitting a magic number; it is designing the research around a question you genuinely need answered.

This is one of the more subtle myths because it often hides behind the idea of sticking to the plan. Once a roadmap has been agreed, there can be a lot of pressure to follow it, particularly if significant time and money have already been committed. But a roadmap is a plan based on what you know today. If you learn something that changes your understanding of the problem or the market, refusing to respond simply because it wasn't in the original plan isn't discipline. It is ignoring useful information.

Imagine that you launch a feature expecting it to become one of the most important parts of the product, only to discover that users barely touch it. At the same time, another part of the experience is getting far more attention than expected. You now have evidence that your original assumptions were incomplete. The sensible response is to investigate why, not to keep investing in the original idea just because it appeared on the roadmap six months ago.

Good product teams create room for this kind of learning without allowing the roadmap to become a free-for-all. There is a big difference between changing direction because the evidence has changed and changing direction because somebody has had a new idea on a Tuesday afternoon. The first is informed product development; the second is usually how scope creep begins.

Once you start thinking about all the people who could use a product, it is very easy to design for everyone. You add support for different customer types, unusual scenarios, edge cases and future opportunities, and each addition feels sensible in isolation. Eventually, though, the product becomes harder to understand for the people who need the core experience most.

A focused first version gives you something much more valuable than a long feature list: a clear opportunity to learn. If you know which users you're prioritising and what job you're helping them complete, you can make deliberate decisions about what belongs in the first release and what can wait. That doesn't mean ignoring other audiences forever. It means resisting the temptation to solve every possible problem before you've properly solved the most important one.

This is where product strategy can have a significant impact before development begins. The job isn't simply to create a backlog of features. It is to establish the priorities behind that backlog so that, when new ideas inevitably appear, you have a framework for deciding whether they genuinely move the product forward.

After months of planning, designing, developing and testing, launch can feel like the moment everything is finally done. In reality, it is the point where your product starts generating a completely different kind of information. Before launch, you're working with interviews, prototypes, assumptions and controlled tests. After launch, you have real behaviour from real users in real circumstances, and that can tell you things no planning session ever could.

You can see which features people actually use, where they abandon a journey, what they return to, what they ignore and where they need help. You can compare what people told you they would do with what they actually do. That doesn't make the earlier research pointless; it completes the picture. The product has moved from being something you are predicting to something you can observe.

This is why launch should really be thought of as another learning cycle rather than the end of the process. The guidance recommends continuing research through beta and live stages, using usability testing, analytics and feedback to understand performance and identify improvements. The same thinking applies to commercial apps and digital products: once people are using the product, you have an opportunity to make decisions based on evidence rather than assumptions.

There is an important distinction between testing a product and testing whether you are building the right product. Both matter, but they happen at different levels and throughout the journey. QA is essential for making sure the finished product behaves reliably, securely and consistently, but quality shouldn't begin when development ends. You can also test the problem, the assumptions, the user journey, the design and the proposed solution long before everything has been built.

That matters because the cost of finding a problem generally increases as you move further through development. If a prototype shows that users don't understand a journey, you can change it before development. If a developed feature reveals the same issue, you may now be looking at design changes, development work, testing and potentially a delayed release.

This is one of the reasons we put so much emphasis on getting the thinking right before a project moves too far into development. The goal isn't to create a huge amount of documentation for its own sake. It is to give the team enough clarity about the problem, users, priorities and risks that development is moving towards something worth building.

Speed gets a bad reputation when it is confused with rushing. Moving quickly shouldn't mean skipping research, design, security or testing. It should mean reducing the amount of time between making an important decision and finding out whether that decision was right.

That might mean creating a prototype before writing production code, testing a key journey before building the rest of the app, prioritising the highest-risk assumptions first or launching a focused version rather than waiting until every possible feature is ready. The point isn't to do less carefully. It is to avoid doing large amounts of work before you have enough evidence that the work is heading in the right direction.

Users don't see the effort that went into your product; they experience the result. Research into mobile page speed found that 53% of mobile site visits were abandoned when pages took longer than three seconds to load. It is a useful reminder that the work happening behind the scenes only matters when it translates into a better experience for the person using the product.

Perhaps the most useful way to think about all of these myths is to stop treating product development as a straight line. It is tempting to picture the process as idea, design, development, launch and done, because that gives you a neat sequence to follow.

In reality, good products tend to develop through a loop: understand the problem, form a hypothesis, prototype a solution, test it, learn from the result, build what makes sense, measure what happens and then use that information to decide what comes next.

That doesn't mean you should constantly change direction or build without a plan. In fact, the opposite is true. A strong product process gives you enough structure to make deliberate decisions while leaving enough room to respond when reality tells you something you didn't know before.

The key is knowing which assumptions are worth testing. You don't need to validate every tiny decision with a research project, but you should be especially interested in the assumptions that could make the biggest difference to whether the product succeeds. Ask questions such as…

• Is this actually a problem people have?
• Is it painful enough for them to care about solving?
• Are we targeting the right users? Does this solution make sense to them?
• Will they understand how to use it?
• Are we building something that creates enough value for them to come back?

Those are the questions worth answering early, because the answers can shape almost everything that follows.

When you're investing time, money and energy into a new product, wanting certainty is completely understandable. You want to know that the idea will work before you commit to it, that users will love the features you've planned and that the roadmap you've agreed today will still make sense months from now.

But certainty isn't something product development can promise you at the beginning. What it can give you is a process for becoming more certain over time. Every conversation with a user, every prototype test, every release, every piece of analytics and every piece of feedback can replace an assumption with evidence.

That is why the strongest product teams aren't necessarily the ones that had the perfect plan from day one. They're the teams willing to challenge what they think they know, test important assumptions early and change course when the evidence tells them to.

For product owners, that mindset can make the difference between simply getting a product built and creating something that has a genuine reason to exist. And for the teams building alongside you, it creates a much better foundation for making decisions about strategy, design, technology and development.

At The Distance, that's the part of product development we care about most. We don't see our role as simply taking a specification and turning it into an app. We want to understand the problem behind the product, challenge the assumptions that could put it at risk, work out what needs to be learned and then use that understanding to shape what gets built.

Because your first idea doesn't need to be perfect. Your product doesn't need every possible feature. And you don't need to know everything before you start. What you do need is a willingness to learn, a clear understanding of what matters and a product process that lets real users help you decide what comes next.