At The Curve, we build products for our clients. These could be business systems that are used by internal stakeholders that we develop using a product mindset, or B2C products our clients then use with their own customers.
Building a product or system is not easy, there are many pitfalls and obstacles that often have to be navigated. In this post, we share some of the common pitfalls to avoid when considering how to build out a system with a product mindset.
1. Dont forget the “Minimal” part of a Minimum Viable Product (MVP)
All products start from an idea or hypothesis for how a particular problem could be solved using a product. Ultimately, the ideas or hypotheses behind a product are assumptions about what customers and the market want and need.
Assumptions are risky because you can plough a lot of time and effort into assumptions that are incorrect. This is why the idea of launching a Minimal Viable Product (MVP) has gained popularity.
The idea of an MVP has been popularised by Eric Ries in his book “The Lean Startup”. In his book, Ries explains that an MVP is “[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. This approach advocates testing assumptions about a product with real users quickly, reducing wasted time and resources on features that do not resonate with the market.
It’s all too easy when launching a product to fall into the trap of making sure that the first version of a product is perfect or complete. However, the smartest way to ship a product is to build the minimum amount of value as quickly as possible, with the least amount of effort to start validating and iterating on the concept.
Being disciplined in sticking to the “minimal” part of an MVP is difficult and challenging, but if done correctly, you’ll maximise getting to market quickly and being able to incorporate real customer feedback into the next iteration of your product.
2. Understand Complexity
Building a complex version of a product can take a lot of work. If your first iteration of a product supports complex scenarios and functionality, you’ll spend more time and effort than you should developing your MVP because complexity takes more time and effort to implement. All of this extra time and effort will delay you being able to start getting any validation of what you’re building.
“A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.” – John Gall, Systemantics (1975)
A product may aspire to solve complex issues and problems, but this can and should be tackled over time, allowing each increment to be validated by the market and customer demand.
Whilst I find Gall’s statement that “a complex system designed from scratch never works” a bit extreme, it does prove the point that you can more easily build a complex system from well-designed, simple building blocks. In contrast, a complex system isn’t readily decomposed into simple building blocks.
It is also worth noting that complexity with a product can often arise when dealing with the “negative” use cases of the “sad paths” of a customer journey.
Let’s imagine we’re building a subscription service, where a customer can use the service for £5/month.
The happy path is very straightforward. If the customer has enough money, correct payment details, etc., we simply take their money and allow them access to the offered service. And with each month that goes by, if the customer stays on the happy path, we continue to take their money and provide them with access to the service.
However, what happens if we encounter a “sad path” where the user doesn’t have enough money when the next month rolls around, and the next £5 subscription fee is due? We could suddenly find ourselves having to tackle the following scenarios in our product:
- Contacting the customer to let them know of the billing issue
- Automatically retrying to take the payment the next day or allowing a customer to retry the payment
- Allowing the customer to change the payment method in case the payment card has expired, or the bank account has since closed
Not only does our system have to deal with the initial sad path of “the customer hasn’t paid on time”, but we also have to entertain a number of scenarios and options to help get the customer back onto the happy path.
Sad paths in customer journeys breed complexity, and often end up delaying getting an MVP or prototype of a feature out the door.
3. Constraints are Helpful, Be Selective
Often, when we speak to clients about the product that they want to build, we end up with a long list of mandatory requirements, and a very short list of requirements that are desirable or optional.
A common pitfall when building an MVP is to have too much in the “mandatory” category. Often, everything is mandatory due to the absence of a concrete understanding of what truly delivers value.
Some of the most successful MVPs that we have worked on have been where the client has been strict about launching quickly, and has been courageous in cutting scope to build as little as possible to launch as quickly as possible.
Whilst it may be difficult, sometimes asking yourself, “what would I prioritise if I only had 50% of my budget?” can be a good way to start flushing out what really is a priority.
Being selective beyond just whether something is mandatory or desirable can also add significant value. We’ve already discussed how supporting sad paths breeds complexity and introduces challenges and complications. Sometimes, what makes a product great is not just what it does, but what it doesn’t do. Sometimes, having the discipline to avoid certain customer challenges or problems and simply deciding not to support a given scenario can result in a far superior and more focused product.
4. You Are Not Your Customer
Stakeholders, particularly those with significant influence or investment in a product, may sometimes favour their own opinions and assumptions over the actual needs and desires of customers and the market. This bias can stem from personal experiences, internal pressures, or a strong belief in the original vision of the product. However, such an approach can lead to incorrect decisions, resulting in a product that fails to resonate with its target audience.
It is important for stakeholders to hold their opinions weakly, remaining open to new information and be willing to adapt their views based on empirical evidence. By validating assumptions through customer feedback, data, and market testing, stakeholders can ensure that their decisions are aligned with what the market truly wants, ultimately leading to a more successful product.
5. Innovation vs Unnecessary
Innovation can drive success, but it’s a fine line between creating something groundbreaking and solving a problem that doesn’t need to be solved. Before pursuing a new idea, it’s crucial to understand why competitors haven’t already done it. This gap might seem like an opportunity, but it could also indicate that the market demand isn’t there or the solution isn’t viable.
Customer feedback is essential in navigating this balance. Engaging with potential users early on allows you to validate assumptions and refine your ideas, ensuring that your innovation addresses real market needs. Feedback acts as a reality check, guiding you to focus on a solution that truly matters and resonates with your audience, rather than creating something that adds novelty rather than value.