We recently talked with a leader at a company that had invested in extensive training from a well known product training company on product discovery and strategy. She was dismayed that the training hadn’t really led to any behavior change. “Most of our teams aren’t doing products, so it just wasn’t relevant for them.”
As we dug into it, it turned out that the working definition of “product” in their company culture was “something an end-customer buys and uses.” Many of the PMs who’d been to the training were working on internal tools like CRM and ERP systems. Those didn’t meet their definition of “product.”
It makes sense how you’d end up there. Read the literature or search the web, and you’ll find most product discovery and strategy content focused on external-facing products. The Lean Startup movement has been a big force in this, pushing lightweight experimentation into the product management conversation. This is a valuable contribution, but the Lean Startup case studies are inevitably, well, startups. They’re trying to sell products to external target customers. So, it’s easy to get the impression that you’re only really working on a product if someone outside your org is paying for it.
But that’s not the most useful way to think about products.
In our experience, if your team builds something for someone else to use to get some value, most of the product skills and tools will apply. For all practical purposes, you’re building a product.
It doesn’t really matter if someone pays money for it. It doesn’t really matter if your user is inside or outside your organization.
What matters is that you’re working to create something valuable for someone else.
The misconception that only external-facing products are real products leads to treating those internal efforts as traditional project management territory. Just gather the requirements, make a plan, and manage the project.
Only, the plan rarely actually works.
Why? Because internal product development can be just as complex as external product development.
Those internal product development efforts are still creating new things for humans, often with dependencies and at a scale bigger than a single team. Which means many of the complexity-aware product management practices still apply.
Product discovery techniques like customer problem interviews are great for internal and external customers. A-B tests, paper prototypes, feature stubs, and concierge tests still apply.
Customer segmentation still works if all the segments are inside your org. (Indeed, it’s a key part of a complexity-aware change management approach.)
Product strategy still matters, even if you’re not marketing your product to external buyers. Incrementally resolving complexity in your product is actually more important than ever if your product won’t have direct revenue.
For a complexity-aware approach to product management that works whether your customer are inside or outside your organization, join us in an upcoming public workshop or contact us to discuss training and coaching customized for your unique challenges and opportunities.
Last updated