Try this before you read on. Think of one everyday product you could not live without. Your phone's maps app, a payments app, the messaging tool your team runs on. Now ask: how would you make it even more useful?
Most people go quiet for a few seconds, then the ideas start. That small pause is the whole story of product management. The products we love feel finished, until someone decides they aren't. The people who make that call are not the ones with the most talent. They are the ones who believe things, including themselves, can always get better.
What a growth mindset is, and isn't
Psychologist Carol Dweck coined the terms fixed and growth mindset. A growth mindset is not positive thinking or motivational posters. It is a working belief that ability is built through effort, deliberate practice and feedback, rather than handed out at birth.
In product work the difference shows up every day:
| A fixed-mindset PM | A growth-mindset PM |
|---|---|
| Defends the roadmap when data disagrees | Treats the roadmap as a set of bets to be tested |
| Avoids customer calls that might prove them wrong | Seeks out the customers who churned |
| Hears feedback on a spec as a personal attack | Asks reviewers to find the weakest part first |
| Calls a failed launch a failure | Calls it an expensive experiment and writes down what it taught |
| Says "I'm not technical" or "I'm not a data person" | Says "I'm not technical yet" and books time to learn |
The best-known example at company scale is Microsoft. Satya Nadella has described the culture shift he pushed as moving from being "know-it-alls" to "learn-it-alls". The lesson for product teams is that mindset is not just personal. Leaders shape it through what they reward, what they punish and what they ask about in reviews.
What a fixed mindset costs a product team
A fixed mindset rarely announces itself. It shows up as a team that stops asking questions. Over time the costs compound:
- Less innovation. People pitch the safe idea, not the interesting one.
- Less curiosity. Discovery shrinks to confirming what the team already believes.
- More dependency. Everyone waits for the senior PM or the founder to decide.
- Lower engagement and higher turnover. Good people leave teams where they can't grow.
Notice the four inner voices
A useful idea from Otto Scharmer's Theory U is that three inner voices block new thinking: judgement, cynicism and fear. I add a fourth that is common in senior people: superiority. Each has a growth-mindset counterpart you can deliberately switch to.
- Judgement to compassion. "That idea is naive" becomes "What would have to be true for this to work?"
- Cynicism to curiosity. "We tried that in 2021" becomes "What's different now, and what did we learn last time?"
- Fear to possibility. "Sales will kill us if this slips" becomes "What's the smallest version we could ship safely?"
- Superiority to solidarity. "I've done this for 20 years" becomes "You're closer to the customer than I am. What are you seeing?"
Reframe the language you use as a leader
Words set the culture faster than values on a slide. If you lead PMs, designers or engineers, listen to how you give feedback. A few reframes I use:
| Instead of | Try |
|---|---|
| "You're not a strategic thinker." | "Let's work on the strategy section together. Which trade-off was hardest?" |
| "Engineering never hits its estimates." | "What keeps making our estimates miss, and what could we change?" |
| "You're a natural at customer interviews." | "Your preparation for those interviews showed. Want to run the next discovery sprint?" |
| "This launch cannot fail." | "Let's agree what we'll learn if it underperforms, and how fast we'll know." |
| "Are you saying I got the priorities wrong?" | "What would you change about the priorities, and why?" |
Notice the pattern: praise effort and strategy rather than talent, turn blame into a question, and make failure something the team plans for instead of something it hides.
Why growth mindset leads to better risk-taking
Innovation needs risk, and risk needs people who are not terrified of being wrong. The biggest risk for a product team is often taking none. These are the barriers I see most:
- Limiting beliefs. "Our customers would never pay for that." Usually untested.
- Fear of failure. Fewer experiments, missed opportunities, less learning.
- Status quo bias. The "good enough" syndrome: the current product is fine, so why change?
- Change fatigue. Too many reorganisations and initiatives breed cynicism and exhaustion.
- Conformity. Repeating an outdated practice because everyone else does.
- Skill gaps. Not staying current, today most obviously with AI.
The antidote is not bravery, it is design. Make risks small and reversible. Run a pre-mortem before a big launch ("it's six months from now and this failed; why?"). Agree kill criteria in advance so stopping a bet is a plan, not a humiliation. Separate one-way-door decisions, which deserve care, from two-way-door decisions, which deserve speed.
Everyday innovation in three steps
Innovation is not only breakthroughs. Most of it is small, daily improvements to products, processes and workflows. A growth mindset makes you want to improve things; a simple routine makes it happen. I use three steps: define the problem, generate ideas, then test feasibility.
Step 1: Write a SMART problem statement
Most teams are taught SMART goals. Apply the same letters to the problem instead, before anyone suggests a solution. A good problem statement is Specific, Measurable, Achievable to tackle, Relevant to the business and Time-bound.
Vague: "Onboarding is bad."
SMART: "Four in ten new admins at mid-size customers don't finish setup within their first 7 days, and those accounts renew far less often. We want to halve the drop-off this quarter."
The second version tells the team who is affected, how much, why it matters and by when. It also quietly kills ideas that don't move that number.
Step 2: Generate ideas with mind maps and SCAMPER
There are many ideation techniques: Edward de Bono's Six Thinking Hats, random-word stimulus, storyboarding, reverse thinking, role-storming, even brainstorming the worst possible idea. Two cover most product situations.
Mind maps are for a new, undefined problem. Put the problem in the centre, draw branches for its main themes (users, moments, data, channels), add sub-branches, then draw lines between ideas on different branches. The connections are where the interesting ideas usually sit. Mind maps are non-linear and expansive by design.
SCAMPER is for improving something that already exists. It walks you through seven questions. Here it is applied to that onboarding problem:
| Letter | Question | Onboarding idea |
|---|---|---|
| Substitute | What could we replace? | Replace the 12-field setup form with an import from an existing tool |
| Combine | What could we merge? | Merge account setup and the first useful report into one step |
| Adapt | What could we borrow from elsewhere? | Borrow the progress bar and checklist that consumer apps use |
| Modify | What could we enlarge, shrink or change? | Shrink setup to the three settings that matter in week one |
| Put to another use | Who else could use this? | Reuse the setup checklist as a renewal health score for customer success |
| Eliminate | What could we remove? | Remove the mandatory training video before first use |
| Reverse | What if we did it the other way round? | Show sample results first, ask for setup details afterwards |
A rule of thumb: use a mind map when you are exploring, use SCAMPER when you are improving. Mind maps open the space; SCAMPER pushes deliberately on what's already there.
Step 3: Test feasibility before you fall in love
Ideas are cheap. Before any of them earns a place on the roadmap, I put it through four questions:
- Impact: will it make a meaningful difference to the problem we defined?
- Buildability: can we build or implement it with the skills and systems we have?
- Resourcing: can it be funded and staffed within our budget?
- Practicality: will it actually work in the customer's real world, not just in a demo?
An idea that passes all four goes into a small experiment. One that passes two goes back to the board, often with a better idea attached.
A growth mindset turns obstacles into detours, not roadblocks. Innovation is rarely a breakthrough. It is a team that keeps asking how today's product could be a little better.
Try this for the next 30 days
Pick one habit from each column and write them down where you'll see them:
- Start: writing a SMART problem statement before every new initiative, and running one SCAMPER session a month on an existing feature.
- Stop: praising people for being "naturals", and shutting down ideas with "we tried that before".
- Continue: the customer conversations, retros and experiments that already teach your team something.
Thirty days won't transform a culture. But it will change how your next planning meeting sounds, and that's where every culture change starts.
