Product vs Feature teams

Marty Cagan writing about Product vs Feature teams:

In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.

When I talk and write about how tough it is to be a true product manager of an empowered product team, it’s precisely because it is so hard to ensure value and viability. If you think it’s easy to do this, please read this.

The lack of giving up control and delegating to your product team is probably the biggest reason I see very few product empowered teams.

Feature teams are set up similarly, but with a stark difference:

However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.

If they say they need you to build feature x, then they believe feature x will deliver some amount of value, and they believe that feature x is something that is viable for the business.

Whichever way you see it; they both are squads but the differences run deep, but I’ll leave you with that I think is the most important

Let’s start with the role of the product manager. In an empowered product team, where the product manager needs to ensure value and viability, deep knowledge of the customer, the data, the industry and especially your business (sales, marketing, finance, support, legal, etc.) is absolutely non-negotiable and essential.

Yet in a feature team, that knowledge is (at best) dispersed among the stakeholders.

Controversial topic but an essential read.

Applying a ‘Time-To-Market’ KPI in product

Gabriel Dan on Mind the Product:

It’s a KPI—used mostly by the business—to measure the time required to move a product or service from conception to market (until it is available to be purchased). The process is the combined efforts of all stakeholders, product management, marketing, and so on. It includes workflow steps and strategies involved throughout the process. It’s usually calculated in days/weeks/months/years but it can be met in other forms too depending on how the different organizations will want to implement this.

This is simply amazing and important especially when you are constantly trying to beat your competition to get out in the market to capture your audience.

The shorter the time to market is, the quicker the return on investment (ROI) can be realized, therefore you can imagine why it’s important for businesses.

The quicker the product gets on the market, the bigger market share the company will get especially in an unaddressed segment facing less competition and thus enjoys better profit margins. Getting fresh and relevant products to market quickly attracts customers.

Exactly. It is very common to get into the phase of doing more before releasing to the market. The TTM metric forces you to be frugal about your MVP.

Gabriel Dan does a great job setting the premise and goes on the explain how the TTM should be calculated. Highly recommended.

Your Product is already obsolete – How to Survive

Des Traynor speaking at Mind the Product San Francisco Keynote:

All startups go through three distinct phases – birth, growth, and survival. You start by making the product work, then you have to grow the product, and then, crucially, you have to focus on survival – on keeping it relevant.

Relevant till date.
One of the best session I ever attended.

Avoid feature bloat and deliver your product strategy

Even the best products including your favorite product (can) suffer form feature bloat. In my last article Measuring Feature Adoption – I talked about measuring feature adoption. Tracking feature adoptions will help you avoid feature bloat.

A product filled with non-performing features causes

1. accumulation of technical debt,
2. increased maintenance costs,

leading to a lower customer satisfaction (NPS score) and a lack of market differentiation.

Features too have an iceberg problem. They may seem to be small features but turn out to have huge costs. This can happen when you decide to ship a feature for a specific customer or a use case instead of shipping new products.

Avoiding feature bloat

One way to avoid feature bloat is to have a strategic approach on the bigger picture. Focus on outcomes instead of output.

Avoid focusing on shipping features. Product teams should focus on the number of problems solved and the positive impact on their customers – this directly results in a better NPS score.

When you focus on the outcomes, it allows you to gather feedback from customers, talk to them more often to test your hypothesis for a new feature. Tracking your feature allows you to decide if you should either iterate or pull out this feature.

Finally, doing a feature audit will also help understand how features are being used. Looking at your feature adoption and usage metrics will allow you to decide to to kill an underperforming feature or work on increasing adoption.

Delivering a Product Strategy

As your product evolves and becomes mature, typically in the growth phase – you attempt to serve everyone. In this phase, products can be disrupted by the one big customer’s specific needs or by smaller niche markets.

Segmenting your product based on customer needs, jobs and personas will allow you to bundle your product to different tiers at different pricing options and avoid feature bloat.

Product Roadmaps

I wont be surprised if every year around this time I’m talking about roadmaps.

Simply put, a product roadmap is a high level plan that organizations use to communicate their plans to achieve their product vision. Product vision is typically driven by the Company’s overall vision.

There is no right way of building roadmaps. I have seen extremely creative roadmaps using images and colors and also black & white flat lists. You use the best (or right) tool that helps you communicate your roadmap to your audience – not one team, several teams.

The product vision at the very highest level talks about Business Objective – how are we going to make money. There is a common theme to all roadmaps and the business objectives tend to fall under two main formats:

  1. Outcome Based which is nothing but an overarching theme or an ability
  2. Feature Based which gets into specifics.

The output for both of these approach is a Product Backlog with Items (PBI) clearly structured and defined.

For example:
Business Objective: Reduce access to item by 30%
Theme: Improve Search Experience
Features: Incorporate Global Searching using keywords

For most part I like taking the outcome based approach as they are better suited for a dynamic market, and themes are less likely to change.

A Feature based approach is well suited for a mature and stable market.

Where things start to break?

  1. The industry today is extremely dynamic and there are 10+ vendors to solve a single problem. The feature based model is fragile and breaks almost instantaneously when their definitions change and new risks or dependencies are uncovered. This tends to erode trust in the product team and its vision.

The best approach is for the management/executives to set the business objectives and empower their product team to determine the themes and features. Delegating builds better leaders.

  1. A good product vision and strategy also tends to fail in the race to meet deadlines. Product teams commonly fail to commit enough time and resources to validate their product strategy.

Basecamp follows a process called Shaping. It’s creative and integrative and a lot of strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?
This allows you to define your scope, experience and value you are going to deliver to your customers.

  1. Roadmaps are typically a journey you undertake for the next 4 quarters – its linear. Building that journey digitally is an iterative process. Roadmaps generally do not include outcomes or features to improve your existing features as you have to keep pace with the delivery train.

Review your roadmaps constantly. They are not set in stone and are bound to change. Product Demos, customer feedback, support tickets, KPI’s are a good indicator if you need to take a step back and revisit things.

Wrapping up; empower your product teams to drive the product strategy and roadmap and make them accountable for achieving business objectives.