How Not to Boil an Ocean: Keeping Product Requests Manageable
A great MVP balances user goals, available time, and an awesome experience. Here are a few ideas to get there. Everything Starts Out Looking Like a Toy, #125
Hi, I’m Greg 👋! I write essays on product development. Some key topics for me are system “handshakes”, the expectations for workflow, and the jobs we expect data to do. This all started when I tried to define What is Data Operations?
This week’s toy: a fast-food restaurant where the food is cooked by people and delivered by robots. I wonder how you’ll tell them that they forgot to add enough ketchup for your fries? Clicking a button on a screen seems like a strange way to do it. Edition 125 of this newsletter is here - it’s December 26, 2022.
The Big Idea
A short long-form essay about data things
⚙️ How Not to Boil an Ocean: Keeping Product Requests Manageable
It's easy to get excited about a great idea. You’re going to change the world! When you get that epiphany and want to translate it into a working product, it's important to keep the pieces manageable. This means breaking down your Big Idea into smaller stories that to refine as the team starts working on bringing them to life. At the same time, you need to be pursuing a track to validate your idea. What makes sense in your head may not be successful with customers.
How do you balance the need to build your Big Idea with idea validation provided by market signals? One answer is to build an MVP (Minimum Viable Product) to get to market. “Minimum viable” in this context means the smallest set of well-built features that convey the eventual vision of the product. Since you can’t build everything you want into a prototype version, it’s tempting to select a thin slice of features across the entire product you hope to deliver.
But a partially built product is not what your customers want. Let’s say you were building a record viewer for a database of song playlists and wanted to offer sorting, filtering, record updating, and a list of all of the records. Creating a single record view might not be enough to give the user a sense of what’s going on. But creating a full-blown search, filter, and inline editing grid might not also be possible given your time or resource constraints.
Why should you build an MVP?
Building an MVP version of your product is a forcing function both for your development team and for your potential customers. If the only features you can include are ones that allow a complete flow, you won’t be able to include everything. The MVP process makes you state the value you are hoping to provide and the way you will prove that vision. A minimum viable product is exactly that: the smallest surface area of the product that is realized enough for a customer to get the idea of what you are delivering.
An actual MVP solves the job the customer has hired you for and does that piece of functionality very well, even if it doesn’t cover all of the features you hope to build. That minimum viable product idea also needs to produce the dopamine hit in the direction of the ultimate product you hope to deliver.
To refine your concept and identify the key components of your MVP, there are a few well-known steps to get there.
First, survey the market - when you find who else is working on the problem, you will see the way it’s being pitched
Set your goals - write down some simple flows for the product that will deliver value
Compare your flows to the outcomes you want - refine ideas using a kano model that balances the ease of use with the capability
Get actual feedback - test a lo-fidelity prototype on a prospect or customer and ask them questions to confirm your Kano model
Iterate and learn - change your prototype based on the information you discover
Survey the Market
The first step to understanding market signals for your MVP is to survey the market. What you’re trying to find out (even if you already think you know) is the set of similar teams and products working on the problem you are trying to solve. You don’t need to do everything better than that team, but you do need to know what they are doing and how they are approaching the problem.
Your best way to find out who’s working on a similar idea? Yep, it’s your friendly neighborhood search engine. If you were researching the playlist idea, you might search “best tools for managing playlists” or if it’s a B2B idea, add “competitors” to the name of a company in the space. G2 Crowd is also a good way to find related companies quickly.
Now, get some first-hand intelligence. For a few of the competitors you just found, check out what they are doing. Go to their website, sign up for a free trial, and use your eyes. Identify one or two things that are working well that you might want to borrow or emulate. Identify one or two things you need to avoid.
Setting MVP Goals
At this point, it’s time to get specific. What kind of goals will distinguish the use of your product from the results someone would get using another tool? For your imaginary playlist app, you might measure:
time to import existing lists
time to create a new list given 10 known songs
number of lists created
measure the number of Spotify followers for this list
Keep your number of goals small - 3 to 5 should do - and write stories to achieve those goals.
Compare goals to flows and write user stories
Creating user metrics gives you a solid rubric to define user flows. If a story or a flow doesn’t have a clear path to your goal, it shouldn’t be in the MVP. For the flows that do advance your goal, they define how a user will interact with the software to achieve a task.
Flows don’t need to be visual to be effective, but they are much better when they include at least a simple sketch of the action you want the user to do to reach the goal. Think to yourself: what are the exact steps they need to do if I were not there that would result in a good result? After you think of the expected case, make sure to include instances where the user doesn’t behave as expected. How will the app respond to unusual input?
For a playlist app, some key flows might include:
Searching for songs to add to a list
Importing existing lists from a music platform
Authenticating against a music platform
Remember, the goal for flows is for people to imagine how it will feel to use the software. They don’t need to be perfect on the first try.
Validation means testing with a customer or prospect
Before you implement an idea, it’s a good idea to validate it. This helps to ensure that the idea is not only interesting but also something that customers will actually use.
Validating can take many forms. Although you can test with internal folks, you’ll get much better results with people who don’t have any incentive to like what you’re working on.
Here are some ideas for learning more about what you’ve built:
if your design exists only as a drawing, show it as a “paper prototype” and ask questions about how it feels
if you have a lo-fidelity prototype, make it at least minimally clickable and let the prospect try it if possible
if you have a high-fidelity prototype, make it something they can try and type into
The goal here is to record the feedback. Ask the user if they could accomplish the task given the information they see - don’t tell them what to do and how to do it. If your design doesn’t pass this bar, go back to the drawing board and alter the prototype. It’s so much cheaper to fix problems now, so don’t be afraid to do it.
Refining ideas using a Kano Model
Perhaps you get some conflicting feedback as you are conducting your user interviews. How do you sort and categorize this information and decide which features to build, and which features to shelve for the next version? One way to do this is to use a Kano Model to compare competing product features. This model was invented in 1984 by Japanese Researcher Noriaki Kano and allows you to measure product features on two dimensions of feedback:
Functionality - how does this feature compare to others of its kind in terms of performance?
https://foldingburritos.com/blog/kano-model Satisfaction - how much delight does it bring to the customer?
from https://foldingburritos.com/blog/kano-model
By graphing these ideas together, you can assess the combination of features that bring the most delight to the customer while also adding capability. When considering a group of things on a limited budget, this is a helpful frame when deciding where to invest time and effort.
In our fictional record viewer, importing existing playlists to edit them might be more important than creating a new one from scratch. Or it might be really important to share and discover lists as the key success metric for the app. If your users don’t react well to the goals you’ve set, it might be a sign that you’re misaligned or that they speak about the problem differently than you perceive.
Avoiding Feature Creep
Now that you’ve checked the market, validated your ideas with prospects, and made some changes to the original design, don’t forget to calibrate your results. How close are we to the original idea?
You now have all of the information for what needs to be in a minimum viable product versus a fully-realized version of that product. As you get a sense of this, you’ll be stacking stories for a future release and also pruning things at the same time.
Feature creep – or continuing to add features without a clear reason to do so - is always a worry. It’s great to have more ideas to improve your product! It’s also necessary to understand how they fit into the overall goals of the product and are worth the effort and time to build.
The first version of our playlist app might omit discovery, sharing, or AI-driven playlist creation, for example. You don’t need to “boil the ocean” to get there. In fact, it’s critical that you limit the number of features you work on to deliver a solid product that users believe will deliver the results they are seeking.
What’s the takeaway?
It’s easy to get excited about a great idea, and important to be mindful of the process you use to validate it so you end up with something end users believe is useful. Validating your ideas before they enter production is a key step in this process, and the Kano Model is one way to balance the utility of potential features you might choose to build.
Links for Reading and Sharing
These are links that caught my 👀
1/ On the benefits of focus time - Do you block focus time on your calendar? Here’s the experience of one team that implemented twice-weekly mandatory no-meeting time.
2/ If you wanted to play in the World Cup - Benn Stancil says you would need to get really good at scoring goals. Ok, this seems a bit on the nose until you think about the role of the specialist in a game when players routinely run 15 miles. How do you maximize the value of the roster (like adding a closer on a championship baseball team)? Add a penalty kick specialist.
3/ So you want to evangelize - John Cutler lays out the steps you’ll need to take to build successful developer relations and evangelism programs.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon