Book Club: Corporate Explorer - How Corporations Beat Startups at the Innovation Game

On its surface, this is not a product book. But Corporate Explorer: How Corporations Beat Startups at the Innovation Game speaks to product managers in two ways. It is filled with examples of new products being built inside established companies. And it speaks directly to the product leader who is fighting the uphill battle of bringing the product operating model to their organization.

The book’s thesis is that established companies have a distinct advantage over startups in the innovation game. They already own the necessary resources, talent, and customer bases to successfully scale new ventures. However, the authors are just as clear that some of those enablers can also trap a corporation into its old ways of working. The answer is an ambidextrous organization that can simultaneously exploit its current core business for efficiency and incremental profit while exploring new, disruptive innovations for future growth. Easier said than done, of course.

The people who take on this valuable work are Corporate Explorers. These are individuals who build new businesses inside their companies, sometimes with a formal mandate and sometimes without, using the company's own assets to move faster than a startup could. The book states, “These are leaders capable of closing the gap between knowing what needs to be done to grow new business and doing so.” 

If you are a product leader trying to change how your organization builds, you may already be a Corporate Explorer.

Some interesting points for product managers:

• In the beginning, work backward from the business you aim to create, not forward from the product or technology you want to sell. This orients you to the customer and the commercial proposition, and away from overindexing on a specific solution or technology too early.

• Winning sponsors is key to the long term survival of any new venture. One way to recruit is to test an incomplete idea with executives and welcome them as advisors. Invite them to learn with you, and they will naturally feel more interested. At some point, a senior team will need to choose your venture over other priorities or initiatives in terms of budget or resourcing. Make sure they know why they should commit resources to you.

• Be an open investigator, which means being aware of the potential biases that you bring to the work. And adopt a discipline that forces you to articulate the logic underpinning your conclusions. Then you can manage the risk that your decisions are likely biased.

• Create good hypotheses about the key issues that will contribute to the venture’s commercial viability. Follow these six business design questions:

  • Customer selection: Who will buy and use the product?

  • High-value customer problem: Does this product address a problem customers care about?

  • Value proposition: Does this product solve the customer’s problem in a way they find compelling?

  • Value capture: Will this product generate enough value for the company to make it worth doing?

  • Ecosystem adoption: Will it be easy for customers to adopt and use this product?

  • Strategic control: What level of sustainable competitive advantage or differentiation can the business achieve?

• Many managers in risk-averse organizations believe they are expected to choose a safe option. Risk aversion becomes a standard feature of a company’s culture, which can be unfortunate for long-term bets.

Some questions for you and your team to sit with:

• In terms of making change within your organization, especially as a leader, it is important to ask the question “why are we doing this, rather than leaving it to a startup?” What is the clear reason that this corporation can achieve the necessary scale more successfully than an independent entrepreneur?

• Within an org, selling the initial vision is relatively easy in comparison to the challenge of sustaining a positive view of what you are doing in the time that follows. Time to revenue doesn’t come as easily in new products or ventures and many leaders can get impatient. How can you manage the flow of bad news, making sure it is always received in a timely manner and with context?

---

I was lucky enough to take Michael Tushman's classes at Harvard while he was developing some of these ideas and teaching case studies that appear in this book. He is an engaging lecturer, and it was an honor to learn from him. His other books, and the advisory work he co-founded with Andrew Binns and Charles O'Reilly at Change Logic, explore these ideas in more depth.

If you are leading product inside a large organization, this book gives you language for work you are probably already doing, and a sharper case for why it deserves support. If you want the practical version, the Corporate Explorer Fieldbook goes deeper on the how.

Alignment, Not Artifacts

AI has made product and UX teams dramatically more productive at producing things. Decks get written faster, summaries get generated in seconds, and documentation that used to take days now takes an hour. That's real, and it can be valuable.

But something is getting lost in the throughput.

When content can be produced that quickly, the temptation is to produce it and send it. Just move. But what is getting skipped is the conversation that used to happen before the artifact existed, the slower and messier process of getting into a room and figuring out what we actually mean. We are increasingly summarizing each other's AI-generated output with our own AI-generated output, and calling that communication.

AI is great at creating artifacts. It cannot create alignment.

Alignment isn't a content problem, and it isn't solved by a better deck or a cleaner summary or a more thorough document. It happens when people with different contexts, different pressures, and different definitions of the same words sit together long enough to close the gap between them. That requires someone who understands the market, knows the users, can read the room, and can translate in real time across all of it. The artifact is evidence of alignment. It's not the thing that creates it.

---

STAND-UP EXERCISE

Pick a word or phrase from your current work, something your team uses regularly and probably assumes everyone understands the same way. "Top priority," "launch-ready," "MVP," and "done" are all good candidates, but the most useful one is whatever is most active in your work right now.

Ask everyone to write down independently what that word means to them - what it includes, what it excludes, and what you would have to see or hear to know it was true. Then compare by mapping on a whiteboard or reading aloud. 

Look for the gap between answers. Chances are, your stakeholders also have similar gaps in their shared understanding.

Discovery as Insurance

Most product teams treat their feedback loop as a form of insurance.

You ship, you watch what happens, you fix what's wrong. That safety net is what lets a team move a little faster than feels comfortable, skip a round of validation, ship the version that's eighty percent right. The cost of being wrong is small, because the correction comes in days. “Move fast and break things” as some tout, or “ship early, ship often”, or even just the practice of continuous deployment.

Some teams don't have that safety net, even if they don't think of themselves as different. A streaming platform building for the Olympics gets one shot at the opening ceremony's traffic. A retailer's checkout flow either holds on Black Friday or it doesn't. A campaign's voter tool has to work on election day, period, with no next release to quietly patch what broke. Tax software has to be right by April, and whatever's wrong then is wrong for everyone, all at once, for a full year.

In each of these, the thing that normally absorbs risk, the fast follow-up, doesn't exist. Whatever assumption is wrong on the day is wrong at full scale, in public, with no cheap way to learn and correct before the next real test. Discovery isn't just the phase before delivery here. It's the only correction mechanism available, because delivery isn't going to offer one.

If discovery is the only insurance available, the real work is finding ways to manufacture more of it before the day arrives, rather than treating the window as pure risk. The attempt is to pull a version of the feedback loop forward, so the team isn't relying on judgment alone when the real day comes.

One move is looking backward instead of forward. Most teams have already lived through a smaller version of their own fixed window and moved on without mining it, last year's midterm elections, last quarter's biggest launch, the summer sale before the holiday one. That data is sitting there, unexamined. It doesn't have to be your own, either. Other companies sometimes publish what broke after their big days, post-mortems, incident reports, case studies. Most teams just don't know to treat this as evidence.

The other move is building a fake version of the day on purpose. A load test that mimics real traffic patterns. A mock election with real people clicking through the real interface. A full internal rollout of the checkout flow before any customer sees it. Even simple tabletop exercises can help a team find flaws in a launch plan before the launch. None of these wait for the real event to teach you something, they construct a rehearsal because the real one hasn't happened yet.

Many teams carrying this type of business calendar don't name it that way. They talk about deadlines, about launch dates, about the big day. Rarely do they talk about it as a loop length, and rarely do they audit their own assumptions against that length honestly.

---

STAND-UP EXERCISE

As a team, name your own fixed window, even if you've never thought of your work that way. It might be a literal event, or it might be a moment where the cost of being wrong multiplies (a big client's onboarding, a seasonal spike, a public launch).

Then ask: what's one assumption we're currently treating as low-risk, something we've silently filed under "we'll fix it after," that actually can't be fixed after? Where are we borrowing insurance we don't have?

Notice where the room gets quiet. That's usually where the real risk is.

Book Club: Product Delight by Dr. Nesrine Changuel

Product Delight by Dr. Nesrine Changuel argues that in a market where almost everything works, working is no longer the differentiator.

Once a product reliably does its job, what sets it apart is how it makes people feel. Changuel, who has built products at Google, Spotify, and Microsoft, set out in her book to "demystify the concept of delight and raise awareness of its power.” What we learn is that delight is something you can design on purpose rather than sprinkle on at the end.

She splits delight into three understandable buckets.
1. Low delight solves a functional need and nothing more.
2. Surface delight speaks to an emotional need but not the core job, the playful flourish that makes you smile and then fades.
3. Deep delight does both at once, solving the problem and earning the attachment.

Her Delight Grid maps solutions against functional needs on one axis and emotional needs on the other, so a team can see at a glance how much of its roadmap is low, surface, or deep.

Source: Nesrine Changuel, "The Delight Grid."

What I keep coming back to is her 50/40/10 rule: roughly half your roadmap on core utility, 40% on deep delight, and 10% on surface delight. It is genuinely hard to balance delight against function, and a simple ratio gives a team shared language for that tradeoff instead of relitigating it feature by feature.

She is just as practical about proving it matters. Rather than trying to put a number on an emotion, she tracks its effects, like moving Skype from a vague satisfaction score to a single operational metric, the Poor Call Rate, that the team could actually move. Each product will have a different way to measure delight, but she gives some ideas on how to get started. The through-line is her case that "when delight is treated as a strategic lens rather than a finishing touch, entire organizations can rally around creating products that are not just functional but unforgettable."

Some questions worth sitting with as a product team:

• If we sorted our current roadmap into low, surface, and deep delight, where would it land? Anywhere close to 50/40/10? (Read her book or website to learn about motivators and how to more accurately create your grid.)

• Where could something we have already shipped be lifted from low delight into deep delight without much added scope?

• What is our version of the Poor Call Rate, the one metric that would tell us whether delight is present or missing?

• If functionality is table stakes in our market, what emotional need is our product really meeting, and do we agree on what it is?

I saw Dr. Changuel speak earlier this year. She was a dynamic speaker, introduced and then in a Q&A with Matt LeMay, whose own book, Impact First Product Teams, I wrote about here. Seeing the two of them together was a nice bit of synergy. What stuck with me was how concrete she was, pulling delight out of ordinary daily interactions and out of her own work as a PM, walking through how she reasoned about these tradeoffs with her team and made the case for them. It is one thing to read the framework and another to watch someone use it to advocate for the work. Definitely a book to add to your professional product library. 

Research Your Stakeholders Like Your Users

Product and UX folks ruthlessly research and analyze their users, to great effect. In fact a closing statement of mine in my team meetings is “go talk to your users”. While there is always room for improvement, this is a skill that we all know and employ well.

An artifact of that is often a user map. At its core, a user map is trying to answer questions around what is this person trying to do, what's getting in their way, and what do they actually need (which is often different from what they say they want). You're looking at goals, pain points, context, and behavior. And crucially, you're looking for the gap between what they say and what they do.

In contrast, the traditional stakeholder map, which we've explored before, is mostly about power and interest. Where does this person sit? How much do they care? How much can they affect your work? It's a useful diagnostic. But it's organizational, not human. It helps you categorize people. It doesn't help you understand them.

An interesting move is what happens when you apply the user research lens to a stakeholder. Instead of asking how much power this person has, you ask: what are they actually trying to accomplish this quarter? What are they afraid of? What are they protecting? What do they say they want versus what do they actually respond to? What context are they operating in that you can't see from your seat? Where is the friction in working with you (even if they'd never say it out loud)?

That's user research, but applied inward.

Designers, researchers, and product managers use this kind of curiosity every day. It's a skill. The shift is simply in recognizing that your stakeholders have pain points too. They have constraints you can't see. They have things they're trying to protect. Treating them accordingly - with the same rigor and genuine interest you'd bring to a user interview - tends to change the quality of the conversation. You can stop negotiating and start understanding.

---

STAND-UP EXERCISE

Choose one stakeholder your team interacts with regularly, perhaps someone whose priorities feel misaligned, or whose feedback is hard to predict, or who you find difficult to bring along.

Using the same empathy map format you'd apply to a user map that stakeholder as a team. Work from what you already know: how they show up in meetings, what they push back on, what they consistently ask for, what seems to matter to them. Note where your knowledge is thin — those gaps are as useful as the answers.

I like to use a virtual whiteboard with the following sections:

• Says: What are they saying about their expectations, concerns, and feedback? Get direct quotes from the stakeholder. 

• Thinks: What are they thinking but might not be vocalizing? Consider their worries, aspirations, and priorities. 

• Does: What do they do in relation to your product? Note the stakeholder's actions and behaviors. 

• Feels: How do they feel about the product or their involvement? Observe their tone and body language.

• Hears: What might the stakeholder hear from others that influences their perspective? Feedback from colleagues, market trends, or industry news…

Once you have this, you can begin brainstorming pain points and opportunities. Try to pinpoint specific areas where the stakeholder faces challenges or frustrations. And then highlight areas where improvements could be made to better meet stakeholder needs and expectations, and improve the relationship.

When you're done, sit with the map for a moment. Does anything surprise you? Where are you making assumptions you haven't tested? Is there a conversation you could have, or a way you could frame your next interaction, that accounts for what you now see? Which of the opportunities are you going to take advantage of?

The goal isn't to psychoanalyze your colleagues. It's to bring the same quality of attention to the people inside your organization that you already bring to the people outside it.