6 Product Development Myths
Any product development process is a balancing act of time, resources, innovation, expertise, research, demanding stakeholders and customers needs, hard work, and more… That’s complicated enough, but what if you buy into one of the myths surrounding product development – what if some of your assumptions about the process are wrong? Here are the most common product development fallacies – the ideas that are easy to believe, even when that belief can seriously (and negatively) affect the digital products you produce.
Table of contents
What do we mean by ‘myth’?
Let’s begin with a definition. The Cambridge Dictionary identifies a myth as, “a commonly believed but false idea”. To put it in digital product development terms, a myth is basically a wrong assumption; a false hypothesis that has become accepted as true. Myths sound reasonable but are characteristically non-evidenced-based. As any developer knows, proceeding on the basis of what you think you know, instead of what the evidence tells you is true, is asking for trouble.
Product Development Myth #1: We must stick to the plan
Yes, planning is important in any project, including the development of a digital product. However, product development is not a simplistic process. As you proceed from the initial or concept toward a finished product, many things will change. New data is gathered, new ideas emerge, new needs are identified, new solutions imagined… and the development that sticks rigidly to its initial plan is unlikely to produce the product users need or want. Which is not to criticize planning, at all. It’s just that requirements change. And the appropriate response is to deviate from the initial plan.
That’s why at Boldare, we work in Agile (as opposed to a Waterfall methodology, which is much more likely to view plans and documentation as sacrosanct - see our article Agile vs Waterfall for more information). Using the Scrum methodology, our development teams are working in short sprints, tightly focused on specific outcomes, and with a double review process (Scrum review meetings examine the work done, while Scrum retrospectives look at how the work was done) that identifies as quickly as possible the need to pivot the process for success.
Product Development Myth #2: Releasing an MVP version of the product is a big risk
By definition, an MVP, or minimum viable product, is not a fully-developed iteration of the product. Often, clients and product owners are concerned that releasing an incomplete version of a product will negatively affect their reputation with users and customers. They think that users will focus on the product’s incompleteness and imperfection, assume the company ‘got it wrong’ or is somehow unreliable and won’t be interested in the final product version… or even in any future product from the company.
Thankfully, this is not true. First, the whole point of an MVP is to release an incomplete version with just the key elements or features necessary to focus user feedback on those elements and features. Second, users are smarter than that – they understand what’s being offered to them.
In fact, releasing an MVP is one of the savviest approaches to digital product development. By focusing on just the essentials of the product, an MVP engages users in the product’s development process, inviting their feedback and input. An MVP validates your product ideas, or doesn’t. Either way, it’s valuable data that can be used to improve the final version.
Product Development Myth #3: The more features a product has, the better
Have you ever used an over-complicated digital product? Maybe a website in which all the latest, most fashionable colors, fonts, images, and animation are present… and completely overshadow the functionality (“Where on earth is the ‘Next’ button?!” or maybe just “Argh! How did I end up here?!”) Or perhaps an online platform where your user account has dozens of settings and options but all you want to do is turn on – or off – the notifications?
Sure, it’s tempting to cram all your ideas into one product but is that what the user wants? Some people love all that fiddling around with the setup. But most are looking for something a little more ‘works straight of the box’.
The key is to focus from the start on the problem or issue the product is trying to solve. What is the specific pain point for users that you’re aiming to address? Elegant, intelligent and successful design is not driven by the question, how many features I can add. It’s more a case of how many features I can leave out and still fully solve the user’s problem. So this is another product development fallacies!
Product Development Myth #4: Failure is not an option!
Of course, it’s nice to not make an error. It’s nice to get everything right from the get-go. But realistically, it doesn’t happen often in life. And in digital product development, aiming to get the product ‘right first time’ is not always realistic.
First, a team aiming not to make a mistake will typically play it safe, designing and developing a low-risk solution. In this context, ‘low-risk’ often equates to ‘least innovative’. Not great if you’re aiming to make a splash in the marketplace.
Second, that same team is likely to do less reviewing and re-examining during the project. After all, the drive to be right first time is also an encouragement to avoid any data or activity that might tell you you’re wrong!
If failure really isn’t an option then surprises, no matter how valuable they could be, are considered setbacks. Considering how user needs and the marketplace can shift and change rapidly, such ‘setbacks’ are necessary to help you create a successful product that fits the requirements. In reality, more experiments, more versions of the product means more feedback, better data, and a refined product vision that is the result of learning from mistakes made along the way. A team that is afraid of mistakes won’t learn, and is unlikely to succeed.
For us at Boldare at least, Agile sprints, rapid iterations, frequent testing, and well-validated assumptions and hypotheses are all key elements of creating award-winning digital products.
Product Development Myth #5: Developers should be in-house
For some, product development should be done by employees, and in-house dev team that are part of the wider organization and fit seamlessly within it. And for some organizations, that is the best option, but for many, it’s just another product development myth.
Perhaps more so than any other specialist role, technology and development’s subject matter is constantly changing – new tools, new technologies, new methodologies… Digital development requires a wide-ranging set of specific and specialist skills that must keep pace with the rate of change. Unless you have the resources and time to maintain such a team of specialists, you’ll be looking outside for a development partner.
The benefit of engaging product development teams from outside your firm is that you can select a partner that already has what you need, there’s no training lag, there’s recruitment delay as you compete for developer candidates with everyone else. Find the development partner that’s the right match for your organization and your product, and you might even get more than you bargained for: knowledge transfer that effectively transfuses greater capability to your in-house workforce, and maybe even a longer-term relationship that could modernize your organization; e.g. through a process of digital transformation.
Product Development Myth #6: one development team fits all kinds of products
For most stakeholders, choosing a product development service provider is mainly a matter of deadlines, budgets, and technology. While those are crucial elements of the bigger picture, many decision makers don’t know or ignore the team factor.
Usually, if a company chooses to work with an external product development company, it gets a team of developers who fit a particular technology, and in the best-case scenario, have experience in working with a similar product. What such a team is missing is experience in working on a particular product development phase. For us at Boldare, it’s crucial because when working on a prototype or an MVP app, you need to have a completely different set of skills than working on a product that is in the product-market fit phase. Here’s why:
- Prototypes are usually done without coding at all (so no software developers are needed);
- MVPs have to be delivered quickly, within very limited scope;
- Product-market fit is all about fine-tuning the product accordingly to the customer segments’ needs;
- Scaling phase demands experienced DevOps Engineers and Solution Architects, who support stability of the developed platform.
This is why at Boldare we work using full cycle product development. It’s an approach that allows us to work on applications taking into account their maturity level. Each phase and its business goal is treated differently. This means that if our potential Partner needs to create an MVP first, we will assemble an MVP team for them. This kind of a team is skilled in working within a limited timeframe, knows how important it is to narrow down the scope to the very viable features, and knows how to validate business goals and product hypotheses. For more information about the full cycle product development read on here.
The development never stops
Many of these product development myths can sound quite reasonable (stick to the plan, don’t fail, more features are good…) until you examine their implications. Almost always, subscribing to a myth means the user is no longer at the center of the development process, and the resulting product doesn’t match the user and market needs.
In reality, the development process never stops, it’s a cycle – after prototyping and MVPs, you need to develop the product further in order to occupy your niche in the market. Then there’s the opportunity to scale up, adding refinements, new features and new users. But at all stages of this full cycle product development, myths are to be challenged, and that’s something to remember about if you don’t want to lose sight of why you’re building a product in the first place. We wish you good luck.
Share this article:
