“In Q1, we launched custom image uploads on desktop and mobile web. For Q2, our goal is to launch support for iOS and launch audio uploads.”
You’ll hear this line of reporting at any many companies. Each quarter or month, when a team has to report to senior management about what their goals are they will rattle of a list of features shipped and another list of features they want to ship next quarter.
Shipping features is a bad goal
Here’s the problem, shipping a feature should not be a goal for your company. Shipping features should be a method to hit a goal you have.
A good goal is one that you can benchmark yourself against. And it’s something you can improve. Improving the rate at which you ship features by 20% might be a goal (a lot of reason why this is a bad one), but shipping an individual feature is not.
Even developer tasks like getting integration tests up and running is not a good goal. Getting integration tests should be something you do in order to hit a goal. The goal might be to reduce QA time by 50%. The goal might be to reduce logic bugs by 25%. The integration tests are a means to get to the goal.
You can’t manage what you can’t measure.
- W. Edwards Deming
Goals should be metrics based. You can’t manage what you don’t measure. How do you know your feature is successful? You must tie that feature back to a metric and goal. Otherwise what’s the point? You ship something that you have no idea what the impact is, you spend a thousand dev hours doing it?
Great job.
Mission accomplished.
Features are the how
Product design tends to be focused on features or “experiences”. Features and experiences are the “how” not the “why”.
The goal is the “why” you’re shipping a feature. The feature only has value if it improves the metric towards the goal. Shipping isn’t valuable unless it can be attached to a “why”.
“We’re shipping iOS support because we want to increase active users by 20% and 50% of potential users are on mobile platforms.”
When you start tying your features to actual value — you’re getting closer to the Job To Be Done of that feature — the real “why”. Not only that, you can measure how effective your feature performs against the “why”. Set your goal and try to hit it with launching features. Don’t make launching features the “why”.
What about my MVP?
What about getting out that first Minimum Viable Product? Isn’t that a goal?
If you’ve read The Lean Startup, then you know that the MVP is a byproduct of something that you’re really after — validated learning. The goal of the MVP is not shipping an MVP, the reason you ship the MVP is to increase your validated learning.
Hiding behind features
It’s easy to hide behind shipping features and think you’re doing well. A company can think of a hundred features to ship — but it’s much harder to tie those features back to meaningful impact towards a goal. Thinking in goals instead of features help you to focus on the Job the feature does instead of the experience the feature provides.
Be honest with your goals. Tie them back to things you can meaningfully impact — just don’t conflate them with shipping a feature.
