- Agile methods for managing the throughput of work… for mature teams that are looking to optimize
- Lean Startup to help teams find what to build… for new teams building the first version of their product.
Turns out I was wrong… kind of.
As with most things, a healthy mix of both seems to be the best solution.
First things first, so what’s the Lean Startup?
The Lean Startup is a methodology based on a repeating, three-staged process:
The aim is to shorten your time in each loop. By doing this, you increase the amount of customer feedback being sent to your team. This feedback allows teams to make more informed product decisions, earlier on.
It’s experimental and does away with making assumptions.
It just makes sense, right?
Agile software development is ‘build focused’
If you start with one if these on their own, you’ll quickly find you’re developing features out of a backlog that’s an “everything bucket”.
That’s because most of these frameworks simply assume that there is a ‘backlog’ which already exists.
Don’t assume you know what your customers need
If product management isn’t your team’s thing, your backlog will probably end up being a mix of:
- All of your team’s ideas
- One team member’s vision of the product
- Features your customers are shouting loudest about
Unfortunately, it probably won’t have a blend of what a great product roadmap has. That is:
- Your product vision
- Customer pain points
- Customers’ jobs-to-be-done
- Customer requests which build long-term value
Don’t forget, these will still be assumptions. Albeit, well-informed ones.
It’s all about product/market fit
“Fall in love with the problem not the solution” — Uri Levine, co-founder of Waze
With a stellar product roadmap in hand and backlog of tasks to work off. It’s time to build, test and validate your ideas.
But first, let’s get back to the basics…
Fundamentally, teams build products to meet the needs of a market. Both change rapidly.
As such, teams should be on a constant pursuit of product/market fit.
Get through the loop quicker with an MVP, then MFFs
Create and iterate upon an minimum viable product (MVP) to validate your product fits a market. 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” — Eric Ries
From then on in, build out the minimal marketable features (MMFs) you identify in your product roadmap. In other words, build features in a way that:
“software is developed and delivered in carefully prioritized chunks of customer valued functionality“
For each MMF, develop just enough to test whether your customers will use the feature. This could mean:
- Creating a ‘feature button’ which says ‘coming soon’ when clicked
- Building the most bare-bones version of the feature
- Blogging about the feature to measure engagement
- and, so on.
Once you’ve built measured and learnt from the feature, either iterate it or pivot to another feature.
It really is that easy.
Although you probably have one last question… how do I decide what my MMFs are in the first place?
How do I decide what to build?
In a nutshell, they focus on the ‘why’ and are what you should base your next features on.
Define your customers’ job stories and document them in your product roadmap so they can be worked on by your product team.
In contrast, a user stories define solutions for how a job story can be fulfilled. That is, a customer’s problems (“the why”) can be solved in multiple ways (“the what & hows”).
Rinse and repeat
Continue to build, measure and learn every-single-day.
And most importantly, never assume.