by Gerry Claps
Let's take a look at what we would usually do:
- Define high level goals (e.g. increase revenue by 10%, increase customer happiness by 2, etc.), and then...
- Prioritize features to achieve these goals (using a 20% effort, 80% result mindset).
Err... how do I find my goals?
How many times have you been able to accurately decide which feature will increase revenue the most? Has this 'knowledge' ever changed which feature you were going to develop anyway?
You're steering the ship, but inside you're probably feeling like this:
But don't worry — high level goals help guide you and that's it.
Of course we want to increase revenue and customer satisfaction! It's a given.
The problem is, finding out how.
Always Be Experimenting (ABE)
To properly define our goals and subsequent features, we have to first acknowledge we have control over three things:
- Making educated guesses
- Testing these assumptions
- Iterating based on feedback
You're probably saying to yourself: "Cool story, sounds like agile software development to me. I'm already doing that".
I tend to agree with you when talking about points 2) and 3).
But... I feel there's a key part that's missing from most peoples' agendas.
Where do my "educated guesses" come from?
While doing all of this, you need to think of the jobs your customers want to do.
Understanding these "jobs" will help you to form the context and situations your customers' are experiencing their problems.
If you can figure out the "job story" of your customers' problems, you essentially know what goals to hit. The solutions will come later.
How could you solve this job? By:
- Inserting a "professional photographers guide for beginners" into the box
- Offering a coupon to a free photography lesson
- Making the camera easier to operate
- and, so on.
The important part about understanding the importance of job stories, is that the solutions matter less than the core job. Once you know the job, you can then prioritize what solutions will solve the job the best.
Become your customer, feel their pain
Now that we know which job (goal) we want to solve, how do you decide what's a good feature to build?
It's simple, build + measure + learn (points 2+3 of Always Be Experimenting):
Build the smallest version of what can give value to your customers (sometimes called the Minimal Marketable Feature), and if they like it (by telling you) or interact with it (by using it) build the feature out. If they aren't, move onto the next best solution.
There's no right or wrong to prioritizing your solutions, you just need to build, measure and learn.
Buckets, 3 to be exact.
So now we have a bunch of goals (job stories) and solutions (usually written as user stories).
Let's get them into order.
(by Foursquare) help you to develop a product roadmap by prioritizing roadmap goals into one of three buckets:
- Now – within the next 2-4 weeks
- Next – this quarter
- Later – beyond
Put each of your job stories and related solutions into a bucket.
Update this frequently. I find a Google Doc works best.
Done! Now rinse and repeat all of the above.