I pressed “publish” on almost three years ago. Someone asked me recently about my “current thinking” on feature factories, so I took advantage of that prompt and gave it some thought. Here are twelve current thoughts on the feature factory challenge. I’ve got more to say on the topic, but this is a good start.
Note: My team recently finished work on the . Many of the points below benefit from having shared language between “the business” and product. The North Star Playbook is a helpful framework for developing that shared language
1. It Takes Practice
It takes practice for a team to move beyond the feature factory. In some environments, getting a moderately usable feature “shipped” is a minor miracle. Not all teams are able to take a more open-ended approach — not due to lack of will or interest, but rather due to practice, and freedom to practice. I once worked at a company that provided a lot of support to new developers and new designers. The goal was to support them in learning how to take a more outcome-oriented approach. And the journey — like anything — took time, practice, and repetition; I’d guess 12-18 months of coaching.
The company was willing to invest time in helping these more junior team-members become truly effective product developers, and the more seasoned product developers were highly engaged instead of being cloistered off doing “real work.” Truth be told, most “experienced” new hires would need a lot of practice. I bring up the “it takes practice” thing with trepidation because I fear it gets used to justify shielding teams and centralizing the “strategic work.” That’s not my intent. But the fact that it is a skill (a skill that can be taught) needs to be mentioned.
2. Best Intentions
Often, it is our best intentions that lead us down the feature factory road. Say you have . It makes sense in this situation to pre-converge on what features to build because you’ll need to juggle who works on what. Before you know it, the roadmap is “locked,” and the team has committed to build a specific feature. We could swap any commonly shared team with the design team here (data science, ops, etc.), and the end-result would be the same. The intention is good — not to overwhelm and overload people — but committing to build features makes it a lot harder to change course when opportunities present themselves.
3. Starting Together
Over the years, has become a mantra of mine. It overlaps many of the points in the original feature factory post. I’ve gotten a lot of pushback on this, especially from folks who feel that it is better for a “small group” (three amigos: design, engineering, and product) to figure things out in advance before landing the effort on “the team”. One big learning is that even with the best intentions, it is common for these “small groups” to land prescriptive work on teams without detailing the bet, and the expected benefit.
So putting aside the debate on how inclusive to make the Start of an effort, it really does boil down to coherence and being able to trace (and communicate) intent. To my earlier point on practice, I get sad when walls are built around this shaping activity. In an ideal world, these team leaders should work shoulder-to-shoulder with the team and model the skill vs. doing it behind closed doors. Doing so goes a long way towards beating that nagging sense that things are just being dropped into a factory. And everyone gets better, together.
4. When the House is Burning
It is impossible to focus on outcomes when the house is burning. In many organizations, it truly feels like the house is burning. Stuff is always breaking in production. There’s always something going wrong. Customer support is blowing up the feedback Slack channel. Everyone is scared because the next issue, the next fire, is lurking just beneath the surface. In an environment like this, it is impossible to really think about outcomes. You can talk about impact, but you can’t focus on it.
Now the smart thing to do in this situation is to really tackle these problems. Stopping the cognitive overload should be priority #1. But that is not what typically happens. Product management works around the problem in a valiant effort to get “something out the door.” Which just makes things worse. Maybe the team asks for a month — the storied “tech debt month” — to get things under control, but on day 32 product is back on the gas. The lesson: get that fire under control. Better yet, put it out. Learning takes attention, and room to breath.
5. Focus on Learning
After publishing the FF post, I had a lot of people contact me with seemingly the same need: proving, once and for all, that strategy X was flawed, or that strategy Y was working. I got reports of engineers refusing to do work until “the plan was FULLY validated!” I feel these folks were looking for something they’d never find in data — namely, trust, confidence, and shared-understanding. What I didn’t mention in that original post, was just how much care and attention it takes to build that trust. Even “high performing” teams will — if they are honest with themselves — fail to move the needle far more often than they make measurable improvements. Reasonable decisions will fall flat. Luck is a big factor.
Anyway, I make especially sure to communicate with more nuance about measurement. Are you able to make marginally better decisions? Reasonably quickly? Are you learning? Or are you using measurement as a trust proxy and a means to control people?
6. Coherence Without Oversimplification
My recent workshops sessions doing belief mapping, assumption mapping, driver trees, and (among many frameworks, etc.) have taught me how important it is to have a shared vocabulary for impact, and ideally a shared mental model for “value creation” (or promise keeping, or job-doing, or whatever you want to call progress in your context). It would seem that half the issue around feature factories is that none of the language around value is aligned. This doesn’t mean everyone needs to think the same way (actually, we WANT diversity and different views)…but at least we can have a conversation about our beliefs.
For example, you’ll have teams talking about revenue, other teams talking about “customer outcomes”, and other teams about conversions. Then someone will come in and try to standardize it all, which just serves to obscure the complex set of connections — the leading and lagging, inputs and outputs, impulses and responses. Or they’ll silo different words into different layers of the org hierarchy. The trick is, I think, to not oversimplify. You need to come up with maps that capture all of the connections, so that anyone can map their work all the way to the one to three year company bets.
7. Chipping Away
Lots of teams take an all-or-nothing approach to overcoming their feature factory tendencies. Based on my work with teams, this is rarely how you make progress. Progress for one team might be extending the time to iterate after “shipping”. Progress for another team might be an after the fact review of a past project. One team I worked with made a huge step by simply admitting that some prior work missed the mark.
This extends to how teams tackle instrumenting their product. They might think that it’s not worth it unless they can instrument every single interaction in their product. Meanwhile, the big decision on everyone’s mind involves a handful of events.
With the original post, I unearthed a ton of angst. Since then, by interacting with more teams on their respective journeys, I’ve witnessed how gradually chipping away can pay off. And please…give teams access to insights. Silo-ing insights — both qualitative and quantitative insights — creates distrust.
8. Lower WIP…Please
I’m persuaded that (work in progress) and optimizing for keeping people busy is at the heart of many feature factory anti-patterns. Without flow, everything will drag. When everything drags, the appetite for anyone to introspect and pivot is very low. When everything drags, you’ll find yourself looking for silver-bullets. Silver-bullets are the feature factory personified.
The low morale you’re seeing may be a downstream effect of high WIP:
High WIP can filter all the way down into whether a team sees itself as a team, or rather as N teams of one. When every person on the team has their own project, you are a lot less likely to engage different perspectives. When product management (or engineering management, this is common as well) busies itself with keeping everyone busy — instead of establishing compelling team-wide goals — you’ll invariably get very busy people.
9. Prescriptive Bets and Coherence
To be fair, there are companies doing “just fine” with their feature factory approach, especially when viewed in terms of how they’re doing against direct competitors (and only looking at the short-term). One of the nuances of the original feature factory post was that placing prescriptive “build this” type bets may be the right approach. A great example might be a fast-follow scenario in a relatively known domain where there are well-known needs (e.g. disrupting on-prem solutions with a cloud-based solution in an established context).
The dysfunction comes when there’s no effort to to understand mid to long-term impact. It is that lack of coherence and discipline that really matters…not whether some bets are prescriptive. In my discussions with teams, I’ve come to understand that the push-back is far more around lack of coherence and blatant success theater, than it is around being able to “own” the solution. The team has a sinking suspicion that all is not rosy. They’re worried that building more and more features isn’t setting up the company for sustainable growth.
And yes, longer feedback loops can be tough to grapple with. You can either “tighten” (shorten) them, reduce the noise, or boost the signal, or all three.
10. Decision Reviews Take Dedication
When I suggest to teams, I rarely get detractors. Sounds reasonable! Why not?! But when the rubber hits the road, you start to realize how little time teams have available for anything that isn’t output oriented. You literally need to carve out this time. Something will always feel more important.
Where I have seen this work, I have invariably found a stubborn VP or Director who integrated it into how everything “worked” and how people worked. They would report initial excitement, then detraction, and then gradual excitement and “dare I say love” for open and transparent reviews. The other key learning: the minute these become adversarial, or are used to rank/grade teams…you lose the essence, and the learning.
11. Accidentally Over-Constraining Teams
Many planning approaches end up inadvertently over-constraining teams — including things like OKRs, which are theoretically supposed to encourage autonomy and an outcome focus. How? Take a quarterly OKRs. How often have you seen teams STOP mid-quarter when the data and learning suggests that an OKR is not feasible and/or in the best interests of the customer and company? Not often. People stay committed, even in the face of disconfirming information. In many cases, the OKRs seem grafted on top of a prescriptive roadmap.
It would be nice if the roadmap was just OKRs. But alas, no. At the end of the day, it is the prescriptive roadmap — and the planning practices around that roadmap — that encourages the , that in turn encourages not leaving time to iterate based on feedback. The key shift is to unify these approaches, , or at a minimum to make the linkages between tactical output-oriented bets, and long-term positive things, more clear.
I’ve observed teams make productive shifts away from fixed-timebox goals like OKRs to something more continuous. A quarter is a long time, and may not give the team enough feedback to improve its approach.
12. Learn By Doing
Finally, it has become very clear to me that the key to all this is actually experiencing new ways of working. Discussions around impact often involve a lot of head-nodding, but not a lot of understanding. The feature factory post triggered a lot of head-nodding. But there’s so much nuance to contend with. My “empowerment” might be your “control freak”. Your “outcome-focus” might be my “top-down decision making”. So at the end of the day, you’ve just got to try it. It takes practice.
And I’m still learning! A great part of my role at Amplitude is that I get to interact with so many teams (mostly customers and prospects, and a bit of internal coaching). I’m learning every day. Final lesson: this is crazy hard, even under ideal circumstances. Be gentle on yourself and your team. With room to practice, things will improve. And the blog posts where everything is neat and tidy and rosy…not so much.