{"id":82284,"date":"2024-07-11T21:41:46","date_gmt":"2024-07-11T20:41:46","guid":{"rendered":"https:\/\/www.prodpad.com\/?post_type=pp_glossary&p=82284"},"modified":"2024-07-15T09:49:37","modified_gmt":"2024-07-15T08:49:37","slug":"feature-factory","status":"publish","type":"pp_glossary","link":"https:\/\/www.prodpad.com\/glossary\/feature-factory\/","title":{"rendered":"Feature Factory"},"content":{"rendered":"\n
\n
\n
<\/div>\n\n\n\n
\n

What is a Feature Factory?<\/h2>\n\n\n\n

A feature factory sounds kind of fun, right? Like a place where all your wildest product ideas come to life in the Product Management equivalent of Willy Wonka\u2019s chocolate factory. With a flowing river of user journeys and geese that lay golden roadmaps.\u00a0\u00a0

Alas, that\u2019s not what a feature factory is.\u00a0

A feature factory is a term used to describe a software organization or team that focuses solely on shipping new features rather than delivering real value to users. Imagine a factory churning out gadgets and widgets without any regard for whether anyone actually needs them or if they solve any problems. The end game is output, not outcomes. It\u2019s about getting stuff out the door and checking off tasks rather than asking, “Is this making a difference for our users?”

You do not want to be a feature factory. Feature factories ain\u2019t good Product Management.\u00a0\u00a0<\/p>\n\n\n\n

What’s the origin of the term \u2018Feature Factory\u2019?<\/h2>\n\n\n\n

The term \u201cFeature Factory\u201d was popularized by Product Management expert John Cutler back in 2016. Cutler used it to highlight a widespread issue in the product development world: the relentless pursuit of more features without considering their impact.\u00a0

The phrase resonated because it conjures up an image of mechanical, mindless production, which is the antithesis of thoughtful, user-centric Product Management.\u00a0

Factories are machines of mass production with a focus on efficiency and scale of homogenous output. That doesn\u2019t sound very in tune with modern Product Management does it? Where\u2019s the strategic thinking, product discovery<\/a>, customer-centricity, and iteration?\u00a0

John wrote a now famous blog on the subject for Hackernoon, entitled 12 Signs You\u2019re Working in a Feature Factory<\/em><\/a>. The drawing John created to illustrate this feature factory concept shows a factory line fed with \u2018stuff to build\u2019 which then outputs at the end of the conveyor belt, one by one, creating a pile of features constituting \u2018the product\u2019.\u00a0<\/p>\n\n\n\n

\"John<\/figure>\n\n\n\n

Check out the customer at the end – they don\u2019t seem convinced. <\/p>\n\n\n\n

Feature Factory vs Agency Trap<\/h2>\n\n\n\n

How does this concept of a feature factory relate to another phrase you may have heard of, namely, the Agency Trap<\/a>?\u00a0

The Agency Trap is a term coined by Janna Bastow, inventor of the Now-Next-Later roadmap (and our very own CEO and Co-Founder here at ProdPad). The Agency Trap describes the phenomenon of building features to order – much like a software agency does.

Now, if you are, in fact, a software house or agency, then that is your legitimate business model. And that’s fine. You fulfill software projects for individual clients with specific requirements. However, if your ambitions are to function as a product-led company<\/a>, building valuable product\/s for a wider base of customers, then the Agency Trap is something to avoid.\u00a0

Both the Agency Trap and the concept of a feature factory are criticisms of a propensity to focus on outputs rather than outcomes – measuring \u2018done\u2019 when a feature ships rather than when desired outcomes are achieved.\u00a0

But whereas the feature factory tends to suppose the \u2018things to build\u2019 have been decreed top-down (take another look at John Cutler\u2019s drawing above), the Agency Trap describes the tendency to have a product roadmap<\/a> populated by customer feature requests taken at face value.\u00a0

The Agency Trap refers to companies with product-led ambitions who actually find themselves building the exact features their customers request, without enough consideration given to the problem they are solving or the extent to which this feature is actually the best way to solve that problem.\u00a0

Read more about how to avoid the Agency Trap in Janna Bastow\u2019s article<\/a> on the topic.\u00a0<\/p>\n\n\n\n

Why do companies become feature factories?<\/h2>\n\n\n\n

Right, we\u2019ve established that you do not want to be a feature factory. But the reality is, it does happen. For a number of reasons, companies can start with the best intentions but find themselves slipping into a feature factory, output-focused mode of working. 

But what are those reasons? How on earth does this happen to a product company?<\/p>\n\n\n\n

1. Pressure to deliver<\/h3>\n\n\n\n

There can exist a proclivity with senior leadership teams, especially when they haven\u2019t come from a Product Management background, to equate more features with more value. Upper management can have a tendency to judge a team\u2019s performance by the output they are seeing. This can be especially true in product development where new features can feel like real progress to senior stakeholders. 

This can lead to pressure from above to prioritize quantity at the cost of quality. Teams want to make their productivity as obvious as possible to protect their jobs. <\/p>\n\n\n\n

2. Misaligned metrics<\/h3>\n\n\n\n

The sad truth is that in some organizations teams are measured by the number of features shipped, not by user satisfaction or business impact.\u00a0

This stems from a reluctance to see Product as a business-accountable function in the same way as Sales or Marketing are often perceived.\u00a0 The perception that the work of Product Teams is a step removed from commercial and business imperatives of a company can lead to the KPIs<\/a> set by leadership for the Product Teams being output focused rather than outcome focused.\u00a0

For example, Product Teams might be measured on velocity, number of features shipped, deployment frequency, number of story points, or other measures of \u2018things being outputted\u2019.\u00a0

If your performance is measured on what you are pushing out the door, rather than the business-critical outcomes of what you ship, then you will end up with a focus and drive directed towards quantity rather than quality.\u00a0\u00a0

Having Product Teams measured on output-focused metrics that are not aligned to the strategic objectives of the overall organization can led a company right down the feature factory path.\u00a0<\/p>\n\n\n\n

3. Lack of vision<\/h3>\n\n\n\n

When a product company (or any type of organization, for that matter) is without a clear and motivating product vision<\/a> or strategy<\/a>, teams will default to a feature checklist mentality. After all, what else have they got to help steer their prioritization?\u00a0

If there is no declaration of what you are trying to achieve with your product – what difference you are trying to make in the world – then how can teams understand what should be guiding their product decision making?\u00a0

In the absence of any clear ambitions or overarching objectives to measure the success of the product against, the fallback barometer of progress will inevitably become features, features and more features.\u00a0

If you are not defining your product by the difference it will make to people, then you are leaving it open to being defined by the sum of its parts – by the total of its component features. And in that case, more features equals more success.\u00a0\u00a0<\/p>\n\n\n\n

4. Fear of not keeping up<\/h3>\n\n\n\n

If teams spend too long watching their competitors and worrying about what they\u2019re doing, there\u2019s a high chance of slipping into the feature factor trap. If you\u2019re constantly worrying about keeping up with your competitors, you could easily find yourself playing catch up, rushing to add features just because you want to match their offering. <\/p>\n\n\n\n

5. Customer requests<\/h3>\n\n\n\n

While listening to the needs of your customers is crucial, blindly implementing every request that comes in can lead to a bloated product without a cohesive strategy. When teams are forced to action customer requests without digging deeper, discovering the real problems to solve and researching and discovering possible solutions, they end up in a feature factory situation. 

This can happen particularly commonly in sales-led organizations where short-term revenue goals trump longer-term strategic product decision making. Where a company has high-value, flagship customers they can weld a lot of power and it can be hard to not action their requests without questioning their needs. <\/p>\n\n\n\n

What are the problems with being a feature factory?<\/h2>\n\n\n\n

If you have found that you\u2019ve fallen into the trap of the feature factory, the chances are you\u2019re experiencing a whole bunch of problems. The pitfalls are numerous! They include:<\/p>\n\n\n\n

1. Overwhelmed and frustrated users<\/h3>\n\n\n\n

Adding feature upon feature without a clear purpose or problem to solve can result in a product rammed with so many new things that users are left confused. 

Too many features that don\u2019t add any noticeable value isn\u2019t a great user experience. You risk annoying your users, making them wade through a sea of \u2018stuff\u2019 before they find what they\u2019re looking for. <\/p>\n\n\n\n

2. Technical debt<\/h3>\n\n\n\n

When you focus on output over outcome the onus is on shipping as many features as you can. When you measure the performance of your Product Development Team by features built, you leave yourself open to work being rushed, resulting in messy code and infrastructure. 

If you\u2019re solely focused on new features, new features and new features, it\u2019s unlikely that you\u2019re taking the time to refactor, revisit things and tidy the code. So technical debt will be mounting up, creating horrible headaches for the future. <\/p>\n\n\n\n

3. Resource drain<\/h3>\n\n\n\n

If your priority is bashing out new features without taking the time to validate ideas, research possible solutions and measure and iterate, then you could well be wasting time and resources on features that do not move the needle. 

You will be getting very little return on investment<\/a> from your product development resources. You will be investing in expensive development without having it impact your business goals.   <\/p>\n\n\n\n

4. Missed opportunities<\/h3>\n\n\n\n

This is particularly true when you find yourself in a feature factory through the pressure of customer feature requests. If the pressure to fulfill important customers\u2019 requests is extremely high, you will likely be building to order without questioning those requests. This is where you could be missing opportunities. 

Without digging deeper into customer requests to uncover what they think that feature will do for them, you will fail to discover the underlying problem and potentially miss the opportunity to explore that further and solve it in a more efficient way for a wider spread of your user base.  <\/p>\n\n\n\n

5. Team burnout<\/strong><\/h3>\n\n\n\n

The constant push to ship feature after feature, without any measurement of outcome and value, will demotivate and burn out your team. You remove the opportunity to celebrate wins and demonstrate the impact their work has on the most important strategic objectives and overall strategy. Job satisfaction is seriously limited in the feature factory.<\/p>\n\n\n\n

15 signs you’re falling into the feature factory trap<\/h2>\n\n\n\n

Are you feeling seen with all this feature factory talk? Did you nod along as you read that list of problems above? If it feels like you might be working in a feature factory, check out our short, sharp checklist and see how many boxes you tick! 

This is the definitive list of red flags to watch out for. Do any of these ring any bells with you? <\/p>\n\n\n\n

    \n
  1. Your roadmap is a never-ending list of features rather than outcome focused initiatives.<\/li>\n\n\n\n
  2. Your roadmap is a timeline. <\/li>\n\n\n\n
  3. Success is measured by the number of features shipped.<\/li>\n\n\n\n
  4. Little to no user feedback is considered before developing new features.<\/li>\n\n\n\n
  5. There’s a lack of clear product vision or strategy.<\/li>\n\n\n\n
  6. Features are added because \u201cthe competition has it.\u201d<\/li>\n\n\n\n
  7. Customer requests are implemented without a second thought.<\/li>\n\n\n\n
  8. Teams work in silos with little cross-functional collaboration.<\/li>\n\n\n\n
  9. Post-launch success is rarely measured.<\/li>\n\n\n\n
  10. High churn rate among team members.<\/li>\n\n\n\n
  11. Over-reliance on new features to drive growth.<\/li>\n\n\n\n
  12. Little attention to user experience and user testing.<\/li>\n\n\n\n
  13. Technical debt is piling up, but new features are still prioritized.<\/li>\n\n\n\n
  14. Product Managers are more focused on project management than product strategy.<\/li>\n\n\n\n
  15. Features are never revisited and iterated upon.<\/li>\n<\/ol>\n\n\n\n

    Your 12 step program for leaving the feature factory and starting to focus on outcomes<\/h2>\n\n\n\n

    First things first, acknowledging you have a problem is the first step to recovery. So let\u2019s hear it. \u2018My name is Bob and I work in a feature factory\u2019. 

    Much like that other famous 12 step program, here\u2019s how you move away from being output-focused to becoming truly outcome-focused.<\/p>\n\n\n\n

    1. Set a powerful product vision<\/h3>\n\n\n\n

    If you need help on how to craft a vision statement that is precise yet motivating and inspiring, we have a vision template<\/a> to help you do just that! Be sure to check that out. <\/p>\n\n\n\n

    2. Define clear objectives and goals<\/h3>\n\n\n\n

    You need to set your product OKRs. If Objectives and Key Results aren\u2019t your preferred goal setting framework, that\u2019s fine – go for something else. The important thing is that you have some sort of overarching objectives and specific and measurable goals underneath them. Make sure they align with the strategic objectives of the overall organization so you can be sure you\u2019re making an impact on what matters most.\u00a0

    Now you have these OKRs, make sure you tie everything on your product roadmap to one or more of these goals.\u00a0

    Which brings us nicely onto\u2026<\/p>\n\n\n\n

    3. Use the Now-Next-Later approach to roadmapping<\/h3>\n\n\n\n

    The Now-Next-Later roadmap is far and away the best example of an outcome-focused roadmap. It was invented by ProdPad\u2019s Co-Founders<\/a> and was designed as the solution to all the problems that come from using an output-focused timeline roadmap<\/a>. 

    As you\u2019d expect from the home of the Now-Next-Later, we have many more resources to help you understand the     benefits<\/a>, how to transition from a timeline to this form of lean roadmap, and even a ready-made presentation to help you convince your stakeholders to make the move to Now-Next-Later roadmapping. 

    A Now-Next-Later roadmap helps you break out of an output mindset by moving you away from features mapped across a timeline, and instead having roadmap     Initiatives<\/a> that focus on a problem to solve. Each roadmap initiative then contains a number of different Ideas which are explore, validating and progressing the ones that your discovery work suggests stands the best chance of solving the problem. 

    You can find out more about the benefits of a Now-Next-Later roadmap through our exclusive course on Agile Roadmapping. Just submit your details to join the course and work through the lessons at your own pace.<\/p>\n\n\n\n

    \"a<\/a><\/figure>\n\n\n\n

    4. Prioritize product discovery and user research\u00a0<\/h3>\n\n\n\n

    Investing time and resource in Product Discovery<\/a> is one of the best ways to ensure that the features you build are the right ones to solve problems and achieve your important objectives. When you prioritize real user research and testing you will truly start to understand your users\u2019 needs, pain points, and behaviors.\u00a0<\/p>\n\n\n\n

    5. Focus on metrics that matter<\/h3>\n\n\n\n

    Shift your focus from measuring output to metrics that measure user satisfaction, engagement, and business impact. Make sure that everything on your roadmap has a target outcome that clearly states the business-critical metric you hope to improve with the delivery of this idea. <\/p>\n\n\n\n

    6. Run hypothesis-driven development<\/h3>\n\n\n\n

    Treat each new idea as an experiment with clear hypotheses and success criteria declared at the start. In this way you are predicting a particular outcome for each feature you build, testing that hypothesis and recording the results of the experiment. 

    This is how you ensure that everything you build is measured and assessed for the difference it makes to users and the business. Without this hypothesis-driven approach, done is done and impact is not considered or celebrated. <\/p>\n\n\n\n

    7. Add post-release stages to your workflow<\/h3>\n\n\n\n

    Don\u2019t end your process when a feature ships, but instead include workflow steps after the delivery stages for measuring results. Here at ProdPad we use \u2018Measuring Success\u2019, after which there are three \u2018Done\u2019 stages – Done | Success \ud83d\udc4d, Done | Experiment Failed \ud83d\udc4e and Done |Inconclusive\/Needs iteration. 

    You can learn more about a best practice outcome-focused product management process by watching our recent webinar     How to Optimize Your Product Process<\/a>. <\/p>\n\n\n\n

    8. Train your customer teams to dig deeper into customer requests<\/h3>\n\n\n\n

    To get out of the feature factory trap it\u2019s crucial that you stop accepting customer feature requests without questioning the motivation behind them. 

    One of the best ways to move from feature requests to genuinely useful customer feedback is to train your Customer Teams to ask the right questions and delve deeper. When they are able to uncover the underlying problem that the customer needs to have solved, you\u2019ll have the insight you need to make the best product decisions.<\/p>\n\n\n\n    \n

    \n

    Learn how to train your Customer Teams to get really useful feedback <\/p>\n <\/div>\n

    \n <\/span>\n <\/div>\n<\/a>\n\n\n\n\n

    9. Establish a continuous feedback loop<\/h3>\n\n\n\n

    To truly move away from the feature factory, you need to take your user feedback extremely seriously. You are no longer taking in feature requests and project managing them through to completion. You are instead asking probing questions, listening to their needs, watching how they use the product and exploring different ways to solve their problems. 

    It\u2019s crucial that you create and maintain     feedback loops<\/a> so you are working with your users to validate and iterate on features. You also need to ensure you\u2019re maintaining a dialogue where you close the loop<\/a> and keep them informed on your findings. <\/p>\n\n\n\n

    10. Build a true product culture with cross-functional collaboration<\/h3>\n\n\n\n

    You don\u2019t want to operate in a silo where Product do their thing, Development do theirs and no one else really understands how the product is evolving, or, most importantly, why. 

    Communicating your product plans throughout the organization will help everyone understand the vision, strategy, objectives and importance of what you\u2019re trying to achieve. When more people appreciate that, you\u2019ll find it easier to push back on pressures to act like a feature factory. <\/p>\n\n\n\n

    11. Build-Measure-Learn to iterate and improve<\/h3>\n\n\n\n

    Embrace and adopt an iterative approach to product development. Focus on constantly learning based on your user data, and continual efforts to drive improvements as a result of your findings. 

    We\u2019ve got a bunch of further reading on this topic, but we\u2019d suggest you start with checking out the concept of     Build-Measure-Learn<\/a> and Continuous Improvement<\/a>.<\/p>\n\n\n\n

    12. Share a outcome-focused roadmap with your customers<\/h3>\n\n\n\n

    One of the best ways of moving away from building to order and the endless conveyor belt of feature request delivery is to publish and share a product roadmap<\/a> that is structured around problems to solve.\u00a0

    Make this available to all your customers and when your next feature request lands, you can ask what problem they think this feature would solve, then show them on the roadmap where and when you are planning to address that problem.\u00a0

    You are letting your customer know a solution is one of your prioritizes, without committing to building the feature exactly how they envisage it.\u00a0\u00a0

    And there you have it, folks! The Feature Factory is a trap that\u2019s all too easy to fall into, but with a clear vision, user-centric approach, and a focus on outcomes, you can steer your product ship towards delivering real value. Happy outcome driving! \ud83d\ude80<\/p>\n\n\n