Part 1 and Part 2 of the “What is Agile?” series looked at the history of agile software development and the best practices development teams can implement.
Building on assumptions
Pretend you’ve just delivered another software project on time and budget. But, there’s one problem: no one is using it. What do you do?
You’d probably think back to when the project started and wish you asked yourself this question:
“What’s the point of developing something really well, if no one uses it?”
If no one is using your product, it’s sitting in one of two camps:
- Your product is great, but you’re having issues with distribution.
- Your product isn’t great, and you’re finding that out for the first time.
It’s common for teams to initially focus on shipping software faster when becoming ‘agile’.
While this is a critical part of being ‘agile’, it’s only effective when you:
“Make something people want” — Paul Graham
How do you know what your customers want?
Well, at first you don’t. And then you do. And then you don’t again. Then you kind of do.
It’s an iterative process.
At the birth of a startup, this process is called finding your product/market fit.
I think a better way of describing it would be the pursuit of product/market fit.
Pursuing Product/Market Fit
As Sean Ellis sees it, finding your product/market fit is the first of three pivotal phases most startups follow.
The market you target is critical, because:
- You change your product according to your market.
- Your market determines how big your startup can become.
If you target a market too small, you can’t grow your product big enough to “make a dent in the universe”. And if it’s too large, you’ll be up against huge competition.
“Product/market fit” can’t be achieved. It’s something you continually optimize and heavily depends on your market.
What’s my market?
Your market is:
Market = ƒ(Jobs to be Done)
That is, your market is the jobs your potential customers want to complete (their jobs to be done). Going deeper, it’s the situations and motivations that lead your potential customers to want to do these jobs.
There’s a number of ways you can better understand your customers (and therefore, your market):
- Show people a prototype of a feature
- Ship a Minimum Marketable Feature (MMF) and measure its performance
- Interview potential customers
- Find potential customer pain points in niche online forums
- See what people are asking for / answering on Quora
- and, so on.
The more context you gather from the above, the easier it is to define the jobs to be done for your market.
After that, you can begin to create a number of solutions (usually, in the form of user stories) to solve your customers goals (i.e. their jobs to be done).
Knowing what people want to do is one thing. Turning it into a software solution is an entirely different problem.
The problem lies with being lean.
If you had unlimited resources and time, you could try everything until you find what works best.
Unfortunately, no one has that kind of runway (well, most people).
The best way to find out what to build (and what not to build) is to validate your assumptions and ideas as fast as possible
Prioritize, prioritize, prioritize!
If you’ve correctly identified your market and what jobs they would like to do, you can now build these out as solutions and get feedback on how to improve them.
How do we build these solutions? Job stories and user stories.
For each job your customer would like to complete (define these as job stories), create a number of solutions that can fulfil them (as user stories).
Any one problem can have multiple solutions. Your job is to find the most effective solutions, and to implement these.
If you build these features with a Minimum Viable Product (MVP) mindset, you’ll find that you can dump or improve your ideas faster than ever.
- If you waste time, at least it was a short amount.
- If it was a great idea, you’ll be able to double down on it faster.
It’s up to you
This is how you be agile. It really is a mindset and not a set of tools.
Continually optimize your product’s fit in the market by minimizing wasted resources, through a focus on experimentation over making assumptions.