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

by Kristen DeLap


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

by Kristen DeLap


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.

Flat line art illustration with five coworkers with speech bubbles above their heads. Some bubbles are shared and similar colored, some are separate and distinct.

Research Your Stakeholders Like Your Users

by Kristen DeLap


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.

Miro board with stakeholder name at top and 7 sections with sticky notes

Identifying Stakeholders

by Kristen DeLap


A key part of product management is managing stakeholders, as most teams require participation, guidance, and approval from a wide range of people across the organization. But oftentimes, product managers treat all stakeholders equally in terms of focus or time expended. A key component to effective stakeholder management is identifying your various stakeholders and grouping them by need. Having this knowledge will help your product team communicate effectively with these groups, and therefore gain early alignment on goals and plans, as well as address any conflict or risk early on.

Often stakeholders can be grouped by their levels of power and interest. A simple two by two can map these out - resulting in four groups: Players, Context Setters, Subjects, and Crowd. (This matrix was popularized by the book Making Strategy: Mapping out Strategic Success.)

The needs of each of these groups are different.

Players
High Interest, High Power
- need to be managed closely
- need high-quality data/insights regularly
- get buy-in on big decisions early
- ask for feedback often

Context Setters
High Power, Low Interest
- need to be kept satisfied
- they can influence the future overall context
- raise awareness with them
- could convert them to players?

Subjects
High Interest, Low Power
- need to be kept informed, "read only" stakeholders
- make use of their interest through low-risk areas of involvement
- "goodwill ambassadors"

Crowd
Low Interest, Low Power
- not worth time to actively manage
- inform via general communications
- aim to move into Subjects

How you interact with these groups in form of the cadence, information provided, and size of audience will all vary. But it is important to keep these general needs in mind, as the more you can tailor communication to gain support or approval from various stakeholders, the more likely your initiatives are to succeed.


STAND-UP EXERCISE

Have your team do a stakeholder analysis by first listing all the groups (or individuals) they know to be stakeholders for your product. Then work to sort these folks into the 2x2 matrix, paying attention to both the level of power and interest. After their needs are identified, the product manager and team can begin to create tailored communication plans, focusing on building and maintaining trust with each of the groups.


Negotiation Tactics

by Kristen DeLap


One of a product managers most used, but perhaps most underrated, skills is negotiation. Almost every conversation a product manager has can feel like a request that needs to be weighed and agreed upon in some fashion. While a product manager can (and should) say “no”, the way in which they get to the no, or verbalize the no, is all about negotiation. It is a key pillar of communication, and one that can affect speed, outcomes, and team morale.

Specific negotiations with a pessimistic developer, or an over-promising salesperson, or an impassioned stakeholder will be different. But there are core strategies that remain the same.

When we think about negotiations, we often think of them as positional - where each party stands in opposition and applies pressure in attempt to get the other to yield. This is most often seen in bargaining transactions, or when someone is talking about “holding a hard line.” However, the better approach is often principled negotiations, where all parties come together as a team to find the best outcome and maintain the relationship. The Department of Product wrote up an informative article that summarizes the findings of the Harvard Negotiation Project on principled negotiations well.

According to the study, there are 4 facets which make up principled negotiation:

  1. People - Try to separate the people from the problem, by focusing on the real issue, not who brought it up. Then be sure to bring in empathy for the multiple perspectives involved, participation from those people, and resist the temptation to get emotional.

  2. Interests - Understand the shared interests, which are common to all parties, and the divergent interests, where they disagree. Also keep in mind many interests can be traced back to security, wellbeing, sense of belonging, recognition, or control, and so try to address these root causes first.

  3. Options - Generating options for an outcome should be separate from deciding, and no option is a bad one when you are just at the brainstorming phase. Then compare and contrast within your list.

  4. Criteria - Attempt to use objective criteria wherever possible in your negotiation to move away from emotional influences. Search for criteria like fair market comparisons, professional standards, scientific judgement or raw data to analyze options.

A product manager even tackling one or two of these strategies in their daily interactions can rapidly move them toward more effective communication. Not every negotiation feels like intense conflict, it can simply be a question of priorities or slightly different goals. Negotiation isn’t inherently a good or bad thing, but getting to the best answer makes a difference for speed, morale, and outcomes. And, importantly, the best answer isn’t winning - it is a result that is good for all involved, takes the appropriate amount of time to get to, and preserves or even strengthens relationships.


STAND-UP EXERCISE

Give a prompt to product managers to ask them about a negotiation conversation they had this week / sprint / cycle. Examples might include - an executive wanted a new feature added to an MVP; do we prioritize working through this technical debt or getting started on this new initiative; the designer wants more time to iterate and the engineers just want to get going; our lead candidate just got another offer for $10K over our budget; do I really need to attend this meeting or can I send another team member…

What went right? What went wrong? Using investigation of the four facets of principled negotiation, where could they have dug in deeper? Be sure to share yourself, as negotiation is not a once-and-done skill, but a learning path for all of us.

A following stand-up could come back to this topic and ask if anyone was able to use these techniques to find a desired or beneficial outcome.

BONUS:
The Prisoner’s Dilemma is a famous game theory problem that shows that single event negotiation is very different from multiple event negotiation. On any given product team, you’ll need to negotiate often, so it is best to stay focused on the long term relationship. Have your team play though this interactive game “The Evolution of Trust” to learn and enact the theory.