Building a Product *Impact* Factory

In an annual review, a board meeting, or even just a recurring check-in, scrutiny is too often disproportionately on features and dates – the stakeholders’ favorite initiatives and when they will be “done.” They want big ideas and a timeline.

• Big ideas signal that the team is working on important things.
• Dates signal commitment and accountability.

89% of product teams we have surveyed feel stuck operating as a "feature factory" all or some of the time. They are focused on executing an endless assembly line of features. This dysfunction is consistently among the most widespread dysfunctions, along with its close cousin the “hamster wheel” – running without getting anywhere.

Besides being exhausting, a focus on outputs over outcomes over-produces the wrong features. This clutters the user experience with features that get launched despite low adoption, and slows development by expanding what the team needs to maintain. The team keeps taking big swings at new ideas, believing that the next feature will be the silver bullet that solve the customer’s problems – despite past performance not justifying this confidence.

What’s missing? Impact – the material improvement of the product’s value proposition. Are the features delivered moving the needle on the product’s overall North Star metric? Is the team making continual progress on the key drivers of customer and business value?

Improving your feature production line

The antidote to this is a series of things that are common sense – but not common practice. Probably you have heard many of these concepts before, or even believe them to be true. However, are you consistently following all of them? From our observations and surveys, the answer is probably no.

The good news is that they probably don’t require a radical overhaul of the team or product strategy, just the discipline to instill these basics and iterate on your own approach.

The feature factory metaphor is valid in that you are managing a type of production process. Although each feature is a unique SKU getting created for the first time, many general operations principles can be applied to improve how you approach your work. In particular, you can look to lean manufacturing for concepts to evolve your focus and produce a higher throughput of stronger, faster results. 

In other words, retool your feature factory to become an IMPACT factory.

Some key elements of that and how to apply them are as follows.

		Clarify the goal
		Manage your team by its constraints
		Instill continuous improvement
		Reduce work in process

Clarify the goal

In your feature production process, what are you producing – and why?

Too frequently, teams confuse means with ends. They have an extensive backlog of vague, one-line feature ideas that sound nice, and constantly get asked by stakeholders about dates for each person’s pet project. This creates a perverse incentive to just focus on building as fast as possible. These teams fear any perceived inefficiencies, so they work to keep engineers as busy as possible..

However, features are means to an end. Engineering utilization is a means to an end. Both have the purpose of 1) improving customer value in ways that 2) help the business make money – now and in the future.

Rather than just focusing on churning through the backlog, pause to reframe and align on the goal.

• Are you clear about your customer’s and team’s key outcomes? Continually improving these is how future value is created.
• Do you know what the key inputs and leading indicators are that will deliver those key outcomes? Often these are the things that are directly actionable.
• Are each of these aligned with key stakeholders (executives, investors, peers, cross-functional pod) so those will support ongoing product focus? Having this alignment makes it easier to say no to unrelated requests.
• Are you tracking progress on these and connecting your roadmap back to them? This helps to maintain focus, as well as validate that your initiatives are moving you closer to your goals.

Our book Build What Matters focuses on defining a vision and the associated key outcomes. A great starting point is defining and getting alignment on your team’s Outcome KPI Pyramid.

For early stage startups these may be less certain – particularly until you achieve product market fit. However even the exercise of defining these and running experiments can be clarifying. Ultimately you want to be able to evaluate 1) can you move the needle on your key metrics and 2) when you do, does that result in customer and business traction?

Manage your team by its constraints

Every production process has its bottlenecks, which determine its overall throughput. This can be a good way to think about your product development process: Improving productivity or outputs in some areas have a disproportionate impact on achieving your overall objectives. 

Once you have identified the most critical metrics to improve, are you set up to make consistent progress on these? Again, progress is defined as improving your key metrics. Usually this means investment in a focused, ongoing program, not merely by delivery of a specific feature. 

Some potential areas evaluate in order to work through your bottlenecks:

• Is it clear who is responsible for delivering the key outcomes? Ideally this includes a directly responsible individual, but also a cross-functional “full stack” team with the skills and capacity to obsess over this area, move quickly, and control their own destiny.
• Once that team is formed, are you giving them the opportunity to focus on this critical problem? Are they empowered to say no to lower priority ideas? Even small unrelated requests consume valuable capacity and distract from gaining momentum – which usually means they are a net negative.
• Are they spending enough time understanding their problem space? The clearer they are, the higher their success rate will be. Also it consumes significantly less of your team’s capacity to discover an idea is “defective” early in the production process rather than defining, designing, implementing and launching a feature – only to discover customers don’t adopt it. Premature commitment to uninformed initiatives often is one of the largest areas of waste!

Instill continuous improvement

Factories – and product teams – are dynamic environments where bottlenecks shift continually. Similarly, the products that customers need shift from both internal factors (e.g. other parts of your platform) and external factors (e.g. innovation by partners and competitors). What has worked in the past is informative but no guarantee in the future. Equally important is to identify, learn from, and act on what hasn’t worked.

Areas to focus on here are consistency in terms of treating each sprint and launch as a learning opportunity:

• Do you consistently evaluate feature launches? Feature launches are a manifestation of a hypothesis that can be proven or disproven – did customers adopt, did adoption solve a problem, did they retain, what else can be learned? Almost always, if something was worth building it’s worth assessing, but most teams do assessments less than half the time and thus miss key insights.
• Do you apply these learnings? It’s one thing to use launch metrics to calibrate your intuition, but almost always there are further actions you should take. Was it a partial solution? Results inform iteration. Was it a huge success? Celebrate, then look for similar opportunities. Did it not work? Roll it back to avoid cluttering your UX and adding maintenance baggage to your platform.
• Does the team also look for ways to improve? Rituals such as sprint retrospectives, recurring team surveys, and other ongoing discussion should inform how the team is operating. Here also it's only valuable if the top feedback gets acted upon!

Reduce inventory/work in process

Many product and engineering teams resemble a factory floor with piles of unfinished inventory and partially assembled products. While these are the components of product development, having a surplus of any leads to a host of problems: long lead times, launch complexity, delayed product improvements, missed learnings, being late to market, and even work obsolescence.

For feature development, this is most evident in a Jira board though work in process can include many things beyond feature tickets. Consider also plans, a backlog of commitments, designs, or any other part of the process that is not yet in the hands of customers, subject to change, or perhaps even wrong.

In some ways, the worst state of a large feature getting developed is 95% complete. The team has incurred most of the effort to build it, but has realized 0% of the value. Even worse, there is a reasonable chance that it won’t meet customer needs, and learning this as early as possible can add value by informing other related decisions.

Many factories have adopted the principles of lean manufacturing in order to manage inventory while increasing their throughput, such as smaller batch sizes and just in time production. Some of these concepts appear in the principles behind the Agile Manifesto, e.g. “early and continuous delivery of valuable software” and “preference to the shorter timescale.”

Some concepts that you can apply to your team include:

• Have you defined the smallest valuable launch? Start with a cupcake. This is a variation on the MVP concept, from Peter Merholz. Make your initial release a complete, delightful experience, but keep it small and simple. You can validate the key concepts faster and often will find that simpler is preferred by customers.
• Are you testing one goal at a time? Avoid the temptation to build “kitchen sink” projects, which try to merge a bunch of loosely related concepts together. You can often simplify and reduce dependencies via: decoupling/sequencing incremental features; isolating to a specific customer profile or geography; validating first and scaling + optimizing later; or using manual support during a proof of concept. Each of these can get you to market – and customer feedback – faster.
• Can you build in serial, not in parallel? Having developers on a pod work on different features means the elapsed calendar time to build is dragged out. It also means others in the pod need to juggle supporting many features in flight, in addition to defining upcoming work or assessing recent releases. This strains efforts to determine the right things to build – one of the most important decisions – and often defaults to “busy work” where developers are given tickets that are easily defined but not necessarily important. By working as a team, things will get launched faster and with better impact.
• Do you have modest buffers to enable fast responses? An over-committed roadmap leaves no room for iteration, application of learning or even to unblock a team member. A plan with every person week accounted for also likely suffers from false precision – planning exact timings based on high level assumptions and requirements. Acknowledging where the team has made a SWAG, or even labeling some initiatives as stretch goals, can give the team a bit of flexibility to respond to the latest needs and opportunities.

Easy ways to get started

Probably you have heard many of the concepts above. Perhaps you are even doing some of them. By design, these are things that you can likely start right away and often without needing any special permission.

No regret moves largely mirror the sections above.

• Clarify and validate overall outcome goals
• Evaluate roadmap and team structure against the goals
• Measure results to calibrate understanding and confidence
• Take large releases and split into sub-phases with ongoing evaluation

As always, we are here to support you in these things as well as building on the foundations.

Feel free to email me at david@prodify.group or request a call.