6 Silly Symptoms Of A Feature Factory

Navigating the hazards of heads-down Feature-Driven Development

Note: This post comes from my main newsletter The Product Post. To gain weekly resources on product and deep-dives on how to improve your strategy and product craft, please consider subscribing to the above! ☝

Like most new professionals to Product Management, I always thought the value of your role was to create fun and cool solutions to solve customer problems.

You know, run some interviews, gain some findings to validate your hypotheses (potentially confirming your own biases), then shipping an extremely functional and simple to use product that is miles apart from your competitors. Easy right?

Take for example, this analytics product I once launched, hoping to cross-sell customers and improve retention. What I thought was a Target Addressable Market of $millions a year, only resulted in achieving a handful of clients adopting it with a shameful ARR.

So, yes, I’ve been there. Wallowing shamelessly in a Feature Factory. I’ve learned now to move on, but only through experience.

But my pain is your gain.

Instead of having to experience these yourself, here’s a short checklist of what I call the syndromes of a Feature Factory, with some quick tips on how to get out of each one.

Let’s dive in.

The Product Post is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Sign up here: https://www.productpost.co/

High Output. Unmeasured Outcomes.

Organisations operating as Feature Factories often prioritize the sheer quantity of features released, measuring success based on output rather than outcome.

Feeling compelled to keep shipment velocity up, a new product owner or manager may not question the metrics and simply ship products, regardless of the quality and impact of it, in an effort not to let others down.

If your PM (or POs if you are inclined) don’t even question or analyse the impact on key performance indicators or business goals during experiments or after launch, start asking big questions, such as these:

• What kind of user benefits and outcomes are these features aiming to achieve?
• What kind of metrics can we measure to link these outcomes to KPIs that drive our business goals?
• (Reverse question) What are our business goals, and what lever or driver does this feature impact, to get us closer towards it?

When it comes to outcomes, start educating your product and engineering team that there are 4 types of outcomes to drive:

• Business Outcomes: The overall results or achievements that directly impact the success and goals of the business, such as increased revenue, improved market share, higher profitability.
• Stakeholder Outcomes: Results that satisfy the interests and objectives of your stakeholders, which may also drive company level metrics and business outcomes
• Product Outcomes: Results related to the performance and success of a specific product or service offered by the business. Example, higher product adoption, increased user engagement, positive reviews.
• Customer Outcomes: Results that solve the problems of your end-users or customers of the product or service. Examples vary of course, but relate to allowing your customers achieving their goals, resulting in greater satfiscation (NPS), user experience, or faster problem resolution.

For each, you can try entering some discussions in workshops to map out your outputs to each of these outcomes. Every outcomes rolls-up to the next, from customer to product, to stakeholder, to business. My favourite method is using a KPI tree, as I mentioned in my Strategy resources. See this Miro board! (p/w coastwithproductpost).

Quantity Over Quality

This syndrome reflects the tendency of a feature factory to prioritise the quantity of features released, in order to meet sales commitments or roadmap imperatives, or even OKRs, often at the expense of their quality.

You may have seen this triangle before: the cost, speed, quality trilemma. Simply put, this is nay on impossible.

Cost + Speed + Quality = Impossible. Would love to hear if you have an example that is all three combined!

Perhaps your organization measures success based on the sheer volume of features shipped, leading to a lack of attention to the actual impact and value those features bring to users and the business.

Perhaps these metrics seem familiar to you:

• Story point velocity
• Number of features released per month
• Speed of deployment
• Bug fixing rate
• Commit count

While some of these metrics may seem useful from the outset, they also are rife for gamification where teams optimise for the wrong metric and ship high quantity at the expense of quality. In the end, we need to remember: Metrics drive behaviour!

If this sounds like your organisation, start to ask your colleagues and your teams about your principles for product development:

• What is the core purpose of our Product team?
• What are our key values? What do we tolerate, and NOT tolerate?
• When challenged with risk and uncertainty how do we make decisions?
• What criteria do we use to decide which strategic priorities are highest?

Unclear or Limited Feedback Loop

A feature factory often neglects the importance of a continuous feedback loop with customers and users. Even in the most technical platform-based products, there’s a role for customer feedback for continuous improvement.

Say for example you are managing a product that is an API-based product that provides cloud-based mobile SMS services:

Here, your customer is a business, but more specifically their software developers. Your platform already processes at what is considered to be a leading SMS success rate (% of messages sent and received successfully) consistent with industry averages.

The company has previously not invested in interviewing their clients, because they have grown immensely through enterprise deals, where churn is starting to grow but is within acceptable range.

In the above case, let’s take two scenarios:

Behaviours of the feature factory:

• Would simply accept that they are doing fine as is, albeit with slight churn starting to appear.
• They decide not to survey their clients on their experience, and decide to simply lower pricing to grow faster, to retain clients commercially.
• They may even start investing large amounts of time on scoping the next feature to build to up-sell existing clients.

Behaviours of a customer-centric product organisation:

• Would survey merchants and their users to continually provide feedback of where improvements can be made.
• In the worst case, they have ideas to improve their product that they do not take action on.
• In the best case, they can unlock revenue far higher than the next new shiny object.

Feedback loops enable teams to gather input from users, allowing them to understand how features are perceived and used in real-world scenarios. This user-centric approach ensures that development efforts align with user needs and expectations, preventing the creation of irrelevant or unnecessary features.

Many Steps. Many Handovers.

In a feature factory, the development process is often divided into numerous stages, each handled by different teams or individuals. This fragmentation can lead to a lack of common understanding of the product’s overall goals, with messages lost between each phase. This leads to what I call the Silo Handover Spiral.

Silos required handovers. Handovers between teams or individuals become points of dependency. Each handover introduces the potential for miscommunication, delays, or misunderstandings, which can slow down the overall development process.

Moreover, a handover-centric approach may hinder effective collaboration between different functional teams (e.g., design, development, testing). Lack of continuous collaboration can result in misunderstandings and a lack of shared ownership of the product.

A lack of shared ownership results in more silos, and hence more handovers again. The cycle repeats over and over.

As work passes through different hands, misalignment with the original product vision or user needs is bound to occur. Lack of continuous involvement and feedback from all stakeholders can lead to products that don’t fully meet user expectations.

To avoid this spiral, simply have a mindset of “Start Together. Finish Together. Improve Together”. Using product discovery kickoffs where product, design and tech are all in the same room validating the problem with data, before ideating a solution, is key.

Be an advocate of cross-functional collaboration, as there really is no downside of it: if anyone tells you more meetings are a waste of time, tell them that it isn’t net new effort, and it will save you headaches in the long-run (especially if you deliver solutions solving the wrong problem).

The Pursuit Of New Business Through New Features

More often than not, companies aim to create new features, simply to close new deals. While there may be great examples of new wins from new features, it is far more often that a company launches products based on the strongest voice in Sales, rather than grounded analysis, and customer insight.

Andrew Chen, partner at Andreessen Horowitz and author of The Cold Start Problem, delves into this idea of a ‘next feature fallacy’ in his blog back in 2015, and it is true even to this day.

The Next Feature Fallacy: the fallacy that the next feature you add will suddenly make people want to use the entire product. — Joshua Porter (Tweet from X.com)

Andrew argues that this fallacy is actually backed purely by data, looking at average retention curves of any SaaS business:

The most ‘tragic curve in tech’ according to Andrew Chen

Some example metrics for a web app with average (but not great) numbers:

— 1000 users visit your homepage to check out your product

— 20% sign up

— 80% finish onboarding

— 40% visit the next day after signup

— 20% visit the next week after signup

— 10% visit after 30 days after signup

— After 30 days, 20 users (out of 1000!) are DAUs

Andrew believes that the vast majority of features won’t bend the curve. With terrible metrics, the Next Feature Fallacy strikes because it’s easy to build new features that don’t target the important parts.

He posits that two mistakes are often made when designing features meant to bend this engagement curve:

• Too few people will use the feature. In particular, that the features target engaged/retained users rather than non-users and new users
• Too little impact is made when they do engage. Especially the case when important/key functions are displayed like optional actions outside of the onboarding process.

A “day 7 feature” will automatically be used less than an experience tied to onboarding, since the tragic curve above shows that fewer than 4% of visitors will end up seeing it.

When faced with the shiny new object, you may see the Next Feature Fallacy strike. In these cases, start to ask your stakeholders:

• What is our average win rate for new features in the past? Why are we confident this time that we can overcome ?
• Under what data points and evidence suggests that customers will adopt ?
• What does our conversion funnel look like and our retention rates?
• What feedback do we currently have from users and what are our CSAT scores? Are there glaring holes that may reduce churn from already paying customers?

By using customer insights and improving specific existing user journeys and use cases, you will unlock more revenue growth than you think!

Too Much Time Spent On Prioritising Initiatives

Don’t get me wrong: a strong prioritisation or decision making process should be implemented in the very scaled of product organisations. That said, there is a large tendancy to overlook another big question: whether or not we are solving the right problem at all, and whether we have evidence to back up this claim.

Often, we look at scores and impact of initiatives based on assumptions (or ideally data), but this endless opportunity and impact sizing may leave not much room for teams to actually validate whether the initiative (often quoted as solutions, not problem areas to improves) are correct.

A telltale sign that you have a feature factory culture, is also in the wording of the initiatives in your roadmap. Let’s consider the following initiative names:

• Redesigned shopping cart 2.0; and
• Improve shopping basket conversion rate by 15% over 3 months

The latter is far more flexible as it is problem oriented, leaving the teams to come up with the solutions that can drive their specific KPIs.

If your roadmap contains initiative wording showing mostly features, functionality, and no outcome-based or problem oriented language, then it’s time to ask yourself a bigger questions:

• What underlying user problem is this initiative aiming to solve?
• What is the biggest problem we need to solve now, and what evidence do we have to validate this claim?
• Does our biggest problem align with the initiatives in our immediate-term horizon on the roadmap?
• What is the impact we want to drive? Is this initiative aligned with business objectives?
• How can I reframe our initiatives towards improving the outcome we aim to achieve, or the impact we want to see?

Tip: You may want to immediately update your initiatives and roadmaps to reflect the answers too.

Final Thoughts

The initial allure of crafting innovative solutions to solve customer problems often collides with the pitfalls of the Feature Factory and Next Feature Fallacy trap.

I walked through 6 Syndromes you should watch out for in any of your product positions:

• High Output. Unmeasured Outcomes
• Quantity Over Quality
• Many Steps. Many Handovers.
• Unclear or Limited Feedback Loop
• The Pursuit Of New Business Through New Features
• Too Much Time Spending on Prioritising Initiatives

I’ve supplied you with some questions to help you guide your teams and stakeholders to get out of each spiral. Let me know how well you go, and what feedback you receive. Would love to see some success stories from the Product Post community!