TBM 26/52: Scaled Feature Factories

In interacting with companies that don’t sell digital products—but who are investing heavily in digital capabilities—I’ve noticed a pattern.

I call the pattern: 

We’re Trying to Do Product, But We’re Handed an Incredibly Overwhelming List of Prescriptive Projects Disguised as Problem Statements With Overly-Ambitious Business Impact Forecasts

• “The business” submits massive lists of features and projects to “digital”

• Someone said you need a business rationale. So someone adds numbers.

• Digital tacks on OKRs and does its best to focus on outcomes…

• But in the end, falls back into being a big feature factory

I saw a list recently with 25 priority areas, broken into ~100 sub priorities, each with a list of projects. 1000 in all. Spanning years. And some OKRs thrown in for good measure. The team desperately wanted to adopt more modern product approaches, but couldn’t.

Why does this happen? This is not a one-off occurrence. I’ve seen this multiple times.

As a product leader, it is easy to take this personally. Don’t! Start by putting your product hat on and making time to understand your partners in “the business”. 

1. By giving specific feature requests, they are trying to make things easier for YOU—easier for YOU to staff your teams, plan your workload, and make reasonable commitments. In many business domains, having a specific request is a show of respect and empathy.

2. Because “tech” is in high demand, there are a lot of incentives to get “on the list” (aka “on the roadmap”). Because “tech” is seen as a precious commodity, every effort is taken to “figure out what you need” beforehand. Planning inventories grow. Utilization grows. Lead times increase. Impatience grows. And everyone has plenty of time to make new requests! Utilization rates are so high that teams have barely a moment to experiment and respond to feedback. Even if they want to. It is a wicked cycle. At a certain point, just shipping prescriptive features is hard…which makes the problem even worse!

3. They need to make commitments to their business partners, and those commitments often include dates and specific deliverables. Those business partners, in turn, make commitments to their business partners. And external partners! And vendors! It’s an intricate network of promises and commitments, often made years in advance. Once in place, it is extremely difficult to adjust anything.

4. They likely work in environments where only concrete, output-oriented plans (with deliverables, milestones, etc.) get green-lighted. Successful pitches have solid solutions—the more visual and compelling the better. Before things reach “tech”, a great deal of sunk cost bias and premature converge has already happened. The idea of starting with a “clean slate” based on the confidence of producing a future outcome is relatively foreign.

5. They likely have experience with “tech projects” being delayed and “taking forever”, but limited visibility into just how many initiatives fail to achieve the desired outcome. A common diagnosis for why efforts fail is that “the requirements were unclear”, which explains efforts to clarify requirements. Why the delays? As my friend Carlog Delgado notes: “these companies don't sufficiently staff the digital side and often don't have enough tech maturity to put good practices in place. Without these, it's very tough to get multiple tries at improving an outcome.” Why the insufficient staffing? For one, until recently they may not have viewed themselves as technology companies! Their product was that other thing they sold for a profit, and digital—formerly known as IT—was just there to grease the chains.

6. For many groups, the main involvement with “digital” is through vendors who work on highly controlled projects (fixed scope, detailed requirements, etc.) Together with the legacy of their now-dismantled—but still strong in spirit—IT organization, there are ingrained beliefs, habits, and expectations when it comes to being a “customer” of “tech work”. It is a customer-vendor relationship, not a partnership relationship. Few team members have actually worked on (or with) an entrepreneurial product team. It’s foreign. Few team members have seen first hand how many efforts fail on the first go. Few team members have seen first hand just how much impact an empowered team, aligned to a compelling opportunity, can have (even when they DO fail on the first couple gos).

7. In digital product selling companies, the business IS the product. Product managers (and whole teams) are expected to have business context. They are expected to have deep knowledge about customers and users. They collaborate with other teams, but it is in service to marketing, selling, and supporting THE PRODUCT. In non-digital product companies there is, frankly, more complexity to wrangle: logistics, merchandising, supply-chain, purchasing, designing THE NON-DIGITAL PRODUCT (shoes, drugs, health plans, financial instruments), etc. The added complexity is real. I feel that some product management writers and teachers underestimate the implications of all this. The net effect is that product teams often lack context. They are not empowered to collaborate with their extended team, so they end up as feature shippers. Even if they want to solve problems, they aren’t really set up to solve problems.

8. Related, it is incredibly difficult to empathize with teams when you aren’t really a team member. In many organizations you see a product manager and business stakeholder schism. In theory, you could have co-product managers. Instead of a “trio” you could invite a business expert on to the team as a team member alongside designers, a product manager, and developers. But it just doesn’t happen this way in most settings. First, there are existing power dynamics. Second, the relationship is buffered through various program management and portfolio management functions. Third, the business owner has a day job. And their boss doesn’t want them spending 100% of their time as a full-time product team member. It’s hard.

I have more, but I think this covers some of the key items. 

If this sounds familiar, trust me it isn’t magic. I hear this story over and over.

The key point here is that it is easy to take things personally. It’s easy to think people are actively looking to disempower you and your team—that they don’t believe you, or diminish what you can do. But a lot of this is just muscle memory. You can’t just loan out Marty Cagan’s Empowered (or Inspired) and magically expect someone to “get” this. And frankly, the game your company is playing is an order of magnitude more complex than a pure digital product company. That’s the reality. Even saying “get this” is putting the onus on them, and not you as the expert.

The onus is on you.

It will take time. It will take innovation. You can’t just copy and paste.

I believe that we are going to see some of the most interesting organizational design models emerge NOT out of digital product companies, but rather out of successful global companies that are figuring out this problem at scale. You’re not playing catch up. You are leading the way.

Each of those 8 items above is something you will need to “lead through”. It will not be easy, but the rewards for the business will make it worth it. 

I’ll do a Part 2 and explore some tactics.