Ship Outcomes, Not Features

A lot depends on which phase of your growth journey you are in. An early stage startup needs to ship lots of things in a very limited amount of time, learn and unlearn things and try to achieve more stability as compared to the previous iteration. 

“If you are not embarrassed by the first version of your product, you’ve launched too late.” – Reid Hoffman, LinkedIn/Greylock

Once any product achieves a certain product-market fit or level of maturity, the focus needs to be more on the outcome of each change than just the change itself.

Shipping any product feature is just one piece of the jigsaw puzzle. Once the feature is shipped, there are many more steps until a measurable outcome is achieved:

• Identify the customer’s pain point
• Build product features
• Drive user adoption
• Get measurable impact (outcome)

The definition of an outcome is different for different businesses. For some, it could be a direct relationship between the feature change and the user adoption, for some, it could be a jump in ‘x’ revenue, while for others it could simply be a change in user engagement time.

While defining the user stories for any product-related change, it is crucial to clearly define the measurable outcomes beforehand. While some might not truly believe in this principle, it is absolutely critical to analyse the success/ failure of that product feature. You might invest a lot of resources to build an awesome UI or an amazing feature, but it might fail to get the attention of your target audience.

At the same time, one needs to be very thoughtful about maintaining the balance between solving customer problems and helping the business to grow and be more successful.

A feature-driven, product-building approach relies mainly on feature requests coming from users or as critical feedback from deal breakers with important clients. In all cases, it’s absolutely crucial to understand the “why” part of it – which is essentially the customer pain point you are trying to solve. Once the main pain point is identified, the next key step is to brainstorm the best approach to solve that problem. The approach should be justified both in terms of the resources it consumes as well as the potential outcome expected. Many times, it becomes difficult to directly tie the approach to the impact it could create – particularly in the context of business growth. Customer behaviour metrics like engagement time, retention, revenue jump etc. in relation to any new change can act as a close proxy to the business impact or expected outcome.

There needs to be a strong feedback loop in place to help get consistent feedback, allowing iteration and the possibility to ship a better version based on the intended outcome. This also helps to steer a current temporary outcome towards a final desired outcome.

An outcome-driven, product-building approach involves starting with a “desired outcome” so as to align the product with the go-to-market strategy. People might argue that this can sometimes be too vague of an approach,, as the team would only have an idea around the KPI metric to build for, but not an exact theory around how to go about it – establishing a clear relation between the solution (product feature and the connected user behaviour around that) becomes tricky with this approach. It Requires a strong link between your solution and mapping it with the key data points (around the desired outcome, for ex-user adoption/ revenue etc.) to track the impact.

A key part of building via this approach is having the involvement of key elements to drive different blocks of the complete puzzle:

• User interaction to get you valuable insights from your actual users who’ll be using the product day in and day out. This requires talking to your customers, sometimes repeatedly, with new lines of questioning. You need to understand what’s going on inside their head while interacting with your product and understanding what they actually need, not just what they want. This is often challenging and time-consuming.

“At the heart of every product person, there’s a desire to make someone’s life easier or simpler. If we listen to the customer and give them what they need, they’ll reciprocate with love and loyalty to your brand."  – Francis Brown, Product Development Manager at Alaska Airlines

• Sales / Marketing insights to help you build a product/market matrix based on field inputs.
• Insights and data points to track and measure tangible outcomes and iterate accordingly, if need be. 

SUMMARY

Product building needs deep research in order to understand customer behaviour – what they like / don’t like about any aspect of the feature. Keeping your users a part of the feature building / refining stage will ultimately help to stitch the business outcome and the product building approach together, and in the process keep iterating on a step-by-step basis through user feedback. The visible output will not always necessarily be heavily proportional to the amount of resources invested or the work, which might make it harder to justify, but that’s just part of the process and in no way should be taken as a setback. The idea is to keep iterating and keep building.