In this instalment of our #Zone5Principles blog series, Zone’s head of engineering, Paul Kiernan, explores creating a ‘true’ MVP — the second and core principle when balancing quality, speed and value. The focus part of this principle is being brave about what ‘true’ means. Done well and the team can deliver a great product at speed, done badly and the product will be bloated, delivered late or compromise on quality.
Creating a lean MVP boils down to one core concept, ‘The product owner’, and five core activities:
- Research
- Ideation and hypothesis building
- Validation
- Mapping the backlog
- Refining the backlog
This blog will focus on research, ideation and hypothesis building and validation. For a detailed look at mapping and refining the backlog, go to part two of ‘Create a true MVP’.
Time after time I’ve seen teams and clients create backlogs that they believe are representative of a minimum viable product, but actually contain a lot of bloat that could be stripped back.
The main problem with the term MVP is that it’s subjective and open to interpretation and opinion. However, there are ways to make this process more objective which we will go into in this article.
At Zone, we’ve created a problem-solving framework called an accelerator that we use to guide teams in creating new products and services. An accelerator is a structured approach to performing research, ideation, validation and ultimately building an MVP backlog, delivery plan and estimates. The accelerator is a topic in itself and something for a future article, however, the following guidance comes from our accelerator model.
Before getting into the article, it’s important to align on terminology. Going forward, I’ll refer to the ticket or backlog item the team ultimately end up building as a ‘feature’.
The product owner…
Never underestimate the importance of having a decisive and empowered product owner. This arguably makes or breaks the process of defining an MVP. In the agency world, the PO is often a member of the client’s team and is pivotal in creating a truly lean MVP.
The best and most successful MVPs I’ve seen delivered are down to the PO knowing their business strategy inside and out, being led by data, listening to their team and making hard decisions. I’ve had the privilege of working with some amazing product owners who have been pivotal to the success of the project and overall product.
Conversely, some of the worst initial product releases (I’m not calling them MVPs on purpose) are because the PO either wasn’t empowered or wasn’t willing to make tough decisions on scope, leading to an over-ambitious backlog and ultimately reducing quality and overall value. The key word here is ‘empowered’: they need leadership capabilities and the trust and backing of senior management teams. Without that, you get an ‘output manager’ managing features through a team, rather than strategically focused individuals who can make decisions with the team and stand by those decisions when talking to senior stakeholders.
It’s important to say that the PO isn’t a dictator who has the sole responsibility to make all the decisions themselves. They should work with their team of advisors, generally made up of experience design, engineering and delivery, who consult and guide the PO on what should be in or out of the MVP.
Research…
Before you try and define your MVP you should have completed your research phase, both wide (as discussed in looking at the big picture) and deep focused research, zeroing in on the specific product/service.
Like everything, research should be multifaceted including (but not limited to), understanding business strategy, user research, business processes/stakeholder research, data analysis, and technology research (both existing tech in the business and in the industry).
This research will give the team a huge amount of context to help work with the PO when defining the MVP.
Ideate and hypothesise…
Once you’ve completed your research or often during, you’ll probably start building your idea of what the product will look like. This will include the types of high-level features that are essential for the product/service to function correctly, which is great. It’s important to create space to sit down and give dedicated time to brainstorm these and other potential product ideas to help explore the art of the possible. This process can be run in design studios or collaborative workshops.
It’s important to get ideas out early so the engineering teams can also up with solution hypotheses of how such features can be built. Ideas should be prioritised and taken forward for validation, which we’ll cover next.
Validate…
Once the initial set of ideas is generated it’s important to prioritise them in line with the measurement framework (discussed in looking at the big picture) and validate them with end-users or the business using prototypes.
The validation process often generates more ideas that can be fed back into the ideation process for reprioritisation and validation. In fact, the phases here in reality don’t have hard starts or stops, they merge and are iterated on as required to ensure the team can move with agility.
Like anything in the product/service development process, validation should be a cross-functional exercise, for example, the engineering team will be performing spikes, running PoC or building prototypes depending on the best way to quickly thrash out issues and challenges to the solution architecture.
At this point we’ve done our research, ideated and validated, that process could have taken days or weeks depending on the size of the challenge, ambiguity and many other factors. The key thing is that the PO and the team now have a huge amount of context and ideas built up throughout the process.
The next step is to map it all out — and we’ll discuss how to do that in part two of this blog.
Notes:
This article is part of an overarching series aimed at people who develop digital products or services, either in-house or agency side, and have been frustrated by missed deadlines, poor output quality or the overall experience not delivering the value you hoped for.
The information discussed isn’t new or groundbreaking; however, it is generally talked about separately and in silo. These articles will provide a holistic and balanced view of the key focus areas to help teams move quickly while still delivering value.
It’s an iterative process to get all these practices and processes in place, so start small, experiment, persist with what works and take the learnings from what fails.
For a full introduction to the series please read the series introduction article.
Principle One: Look at the big picture, but don’t get lost in it
Principle Two: Create a true MVP (Part Two)
Principle Three: Picking the right tools for the job
