Journal / Strategy
Innovation lessons for product managers
Three books. Three lessons. Three examples from the field.
Lesson 1: Start with why
Book: Start With Why — Simon Sinek
Sinek's core argument is simple: people don't join uncertain projects because of what you're building — they join because of why you're building it. A clear "why" helps you recruit collaborators, tell a coherent story, and stay focused on the actual problem.
The "why" also connects directly to jobs-to-be-done thinking. If you can't articulate why a problem matters, you probably haven't understood it deeply enough.
Example: Parkinson's detection
Our team built a voice-analysis prototype to detect early-stage Parkinson's disease. A short phone call could screen patients who might otherwise wait years for a neurologist. Technically, we got to 78% reliability — a solid start.
But when we asked "why" five times over, the answer unravelled the premise. There was no treatment for early-stage Parkinson's at the time. Detecting it early would only create anxious patients with nowhere to go. No healthcare organisation would pay for that.
We shut the project down. Not a failure — a fast, cheap lesson that saved us from building the wrong thing. The "why" framework caught it.
Takeaway: Don't just ask why once. Ask it five times. Fall in love with the problem, not the solution.
Lesson 2: Phase separation
Book: Loon Shots — Safi Bahcall
Bahcall argues that what kills innovation in large organisations isn't culture — it's structure. Innovation and execution operate in fundamentally different modes, like water existing as ice and liquid at different temperatures. Trying to run both in the same way causes one to kill the other.
Example: Radar in World War Two
Radar was first demonstrated in 1904 by Christian Hülsmeyer, who discovered he could detect ships in fog using reflected radio waves. Yet it took decades to become operationally useful — not for technical reasons, but organisational ones.
Researchers were exploring long-horizon problems with no guaranteed timeline. Military procurement wanted solutions in under three years or they walked. These two modes were incompatible, and innovation stalled.
What eventually worked was a bridging structure: Vannevar Bush, dean of MIT, set up the Office of Scientific Research and Development (OSRD) to act as an intermediary between researchers and the military. This translator layer made the difference.
Applied to product organisations: Replace "research" with innovation and "military" with product development. The dynamic is the same. Your innovation team works on uncertain, long-horizon bets. Your product team runs two-week sprints against a roadmap. These two modes need to stay partially separate — but not disconnected.
What you need is a person or team in the middle who can translate innovation outputs into product OKRs, de-risk experiments before they hit the roadmap, and manage the transition from exploration to delivery.
Takeaway: Keep innovation and delivery structurally separate, but build a bridge between them. Without the bridge, innovation never reaches the product. Without separation, short-term urgency kills long-horizon work.
Lesson 3: Test big hypotheses fast
Book: The Lean Product Playbook — Dan Olsen
Most teams use prototyping to test small questions: button colour, navigation patterns, copy. Olsen's point — and mine — is that you can test much bigger questions just as quickly. Entire business models. Product concepts that don't exist yet. Speculative technology.
Example 1: Happiness mapping
We had a hypothesis: people might want to see where they feel happiest throughout their day. A supermarket might score differently from their commute, their office, their home. Useful? Interesting?
A three-person team built five landing pages in one week, put them online, and measured conversion. One of the concepts — the happiness map — tested poorly. Users found it childish for the target demographic. We killed it in a week, not a quarter.
Example 2: Mood-sharing wearable
A more speculative concept: detect your mood using behavioural data from your phone, and display it on a skin-mounted device so your partner could see how you were feeling in real time.
We prototyped this with projected visuals on people's arms and invited couples to experience it. The initial reaction was genuine interest. Then came the nuance: "What if I'm having a great time but she's not? Do I feel guilty?" and "I don't want my partner seeing every low moment."
The insight wasn't that the idea was bad — it was that mood-sharing needed an off switch, and that radical transparency in relationships has real limits. That's a valuable finding for a concept that didn't require any engineering.
Takeaway: Prototyping isn't just for small UX questions. Use it to test the big bets — before you commit resources to building them.
Innovation portfolio: how much of each?
A common question is whether PMs should always be chasing big innovations or focusing on incremental improvements. The answer is a portfolio approach.
A useful starting point is the 70/20/10 rule:
- 70% on things you're doing now (optimise and improve existing products)
- 20% on adjacent opportunities (new features, new segments)
- 10% on long-horizon bets (things that might not work at all)
At Telefonica Alpha, we ran closer to 50/30/20, with a larger share in long-term exploration. The right ratio depends on your organisation, but having a deliberate split is more important than the specific numbers.
On discovery vs delivery: roughly 30% of our effort sat in the pure research/exploration phase (within the research team), another 20% in exploratory work within the product teams, and the rest in taking things to market.
Three books worth reading
These aren't abstract frameworks. Each one maps directly to decisions you can make in your next sprint, your next quarter, or your next org design conversation.
