1. Explain why the hell you’re writing this doc

Before you write a single word, answer this question: What decision or action am I trying to enable with this document?

Not “I’m documenting our findings.” Not “I’m sharing an update.” What specific outcome do you want? Do you need approval to kill a feature? Do you need the team to align on a strategy? Do you need stakeholders to understand why something failed so they stop asking about it?

I’ve lost count of how many times I’ve read a document and didn’t understand what the author intended. Do they need feedback? Should I approve it? Or what?

Bad: “Document our Q3 learnings”

Good: “Get VP approval to invest €35k per year in an OCR solution so that we can address 20% of NPS detractors”.

Bad: “Share user research findings”

Good: “Convince the team to pivot our onboarding approach because 68% of users are getting stuck at step 3”.

Once you know your purpose, write it at the very top of your doc. Literally write: “Purpose: Get approval to...” or “Purpose: Align the team on...”

2. Start with the end (the conclusion)

This is not a murder mystery novel. Don’t make people read to the end to find out what you think.

Your doc should start with your recommendation, decision, or key insight. Not on page 7. Not after three sections of background. At. The. Top.

Why? Because your audience is busy, and they need to know immediately if they should keep reading. A CEO scanning 20 docs before a meeting needs to know: “Is this a problem I need to solve now, or can I delegate/ignore it?” Your product lead reviewing your roadmap proposal needs to know: “What are you asking me to approve?”

When you front-load the conclusion, you also force yourself to clarify your thinking. If you can’t write a clear conclusion, you probably don’t have one yet. Which means you shouldn’t be writing the doc—you should be doing more discovery or analysis.

Example structure:

“We should kill feature X and invest those resources in feature Y instead. Feature X has 3% adoption after 6 months and costs us $50K/month in maintenance. Feature Y addresses our #1 customer pain point in support volume, and a recent survey with 100 customers showed that 67% of respondents consider churning because we lack it.”

Now the reader knows exactly what you want and why. They can decide immediately if they agree or need to read more details.

3. Real executive summaries actually are summaries (of the whole doc)

If I can find key info in your doc that wasn’t summarized in the executive summary, you are doing summaries wrong.

That doesn't mean all the details should be in the summary.

A real executive summary is a miniature version of your entire document. Every major section should appear in the summary. Every key insight should be there. Every important number should be there. Someone should be able to read just the executive summary and walk away with 80% of the value.

Here’s my trick: I write the exec summary at the very end, after I've finished the document and even had some quick feedback from close associates. Then I open the doc side-by-side in two windows. I write each section of my doc in the executive summary. One or two sentences per section. This forces me to clarify what each section actually contributes and if I have a story.

If you can’t summarize a section, that section probably doesn’t need to exist. Maybe it's an appendix? Or maybe it's part of a larger section.

Bad:
“This document analyzes our checkout flow performance and provides recommendations for improvement.”

Good:
“Our checkout flow has a 42% drop-off rate at the payment step, costing us $200K in lost revenue monthly. User testing revealed that 89% of users don’t understand that we accept PayPal. We recommend adding PayPal as a visible option, which similar companies saw increase conversion by 15-20%. Implementation would take 2 weeks.”

4. Tell a story: Problem → Insights → Proposal

People understand stories. They don’t understand disconnected information dumps.

Your doc needs a narrative arc. You’re not just presenting facts—you’re taking the reader on a journey from “here’s the problem we’re facing” through “here’s what we learned” to “here’s what we should do about it.”

Problem: What are we trying to solve? Why does it matter? Quantify the impact.

“Our NPS dropped from 45 to 32 in Q2, driven by complaints about slow load times (mentioned in 78% of negative feedback).”

Insights: What did we discover when we investigated? What surprised us? What did we learn about our users, our product, our market? “

We traced the issue to the reporting feature, which makes 47 database calls every time it loads. Users who use reporting weekly are 3x more likely to churn.”

Proposal: Based on what we learned, here’s what we should do. Here are the trade-offs. Here’s why this is the right path forward.

“We should rebuild the reporting backend to use cached data. This will cost 6 engineering weeks but reduce load time from 8 seconds to under 1 second, directly addressing our top churn driver.”

This structure works because it mirrors how people naturally process information and make decisions. It also ensures you’ve done the work—if you can’t clearly articulate the problem or insights, you’re not ready to make a proposal.

5. Actually write it like a story (connect to the next step)

Related to the point above, but worth separating: your sections should flow together like chapters in a book, not feel like disconnected slides slapped together.

Each section should naturally lead to the next. The end of one section should set up why the next section matters.

Bad:
Section 1 ends: “Our signup conversion is 18%, significantly below the industry benchmark of 35%.”
Section 2 starts: “We interviewed 12 users.”

Good transition:
Section 1 ends: “Our signup conversion is 18%, significantly below the industry benchmark of 35%. We needed to understand what’s blocking users.”
Section 2 starts: “We interviewed 12 users who started but didn’t complete the signup. Here’s what we learned...”

See how the second version connects the sections? The reader understands why you interviewed users—it’s the natural next step in solving the problem you identified.

6. Eliminate every single weasel word

Weasel words are words that should mean a quantity, but don't quantify. Words like “some,” “many,” “often,” “significant,” “substantial,” “improved,” “better.”

Every word that implies quantity must be quantified.

Don’t write “many users requested this feature.” Write “47 users requested this feature in the past quarter.”

Don’t write “performance significantly improved.” Write “load time decreased from 3.2 seconds to 1.1 seconds.”

Don’t write “we saw substantial growth.” Write “revenue grew 23% quarter-over-quarter.”

Why does this matter? Because weasel words let you hide from accountability and clarity. They let you say things that sound good without actually committing to a specific claim. They also make it impossible for readers to evaluate your argument.

If you write “many users complained,” your CEO might think you mean 1,000 users. Your eng lead might think you mean 10 users. When they find out it was actually 3 users, your credibility takes a hit.

Specificity builds trust. Vagueness erodes it.

Go through your doc and replace every weasel word with a number. If you don’t have the number, either go get it or acknowledge you don’t know: “We don’t have data on adoption rates yet, but based on support tickets and sales feedback, at least 15 enterprise customers have asked about this.”

7. Charts don't speak for themselves

When you add a chart with no explanation, what you are doing is making the reader squint and ask, “What should I conclude from this?” Then Slack pops up, and you have lost the reader.

Your chart needs two things:

1. A clear written insight that tells people what they’re supposed to see. Don’t make them interpret it. Tell them: “Revenue from enterprise customers has grown 3x faster than SMB revenue since we launched the admin dashboard in February.”

2. Visual highlights that draw attention to what matters. Highlight the relevant bars. Draw a circle around the inflection point. Add an arrow to the trend you want people to notice.

Think of your chart like you’re explaining it to someone over the phone. What would you tell them to look at? Write that down. Then make sure the chart visually emphasizes those same elements.

8. Run it through Grammarly (or any grammar checker) before you hit send

I don’t care how good a writer you think you are. You’re making typos. You’re writing run-on sentences. You’re using passive voice when active would be clearer. You’re just not seeing them because you’ve been staring at this doc for three hours.

Use a grammar checker.

As a non-native speaker, Grammarly saved my ass many times. But you obviously can choose whichever you think is best.

Caveat: don’t blindly accept every suggestion. Grammar checkers are tools, not gods. Sometimes they’ll flag something that’s actually fine, especially if you’re writing in a more casual or direct style (like this article). Use your judgment.

Also, one bonus tip: read your doc out loud before you send it. Seriously. You’ll catch awkward phrasing, missing words, and unclear sentences. If you can’t easily read a sentence out loud, it’s probably too complex. Simplify it.

If you found this article useful, please smash the “like” button. If you know any PMs who could benefit from it, share it with them. This is a tremendous help to me.

If you wonder why I haven’t written in a while, it’s because I sacrificed all my free time to the gods of prompting, more specifically, vibe coding.

It’s both magical and infuriating.

This is an account of what I learned, so you can skip some of the infuriating bits of vibe coding to go straight into the magical parts.

My vibe coding stack

Lovable, the coding agent

I chose Lovable because my reference for low/no-code tools, Éfrem Filho, recommended it to me. It's a very PM-friendly tool, including an amazing one-click deploy. This means it’s instantly accessible everywhere on the internet, without you having to deal with deployment pipelines, AWS, and whatnot. What this means is that you click a button, and it’s live. You can even get your custom domain with a couple of clicks.

It’s magical for non-technical people. Given the AWS infrastructure's productized and accessible nature, engineers might not fully grasp why non-engineers struggle to deploy something. But for non-techies who had at most coded on localhost, it’s empowering.

Supabase, the backend

Supabase provides your project with a real database, the ability to execute backend code (as opposed to running it in the browser, which is crucial for security), S3 buckets for file storage, a secrets vault, and a straightforward way to implement authentication.

Behind the curtains, Supabase uses AWS, and the database is Postgres. So if your app takes off, a real engineer could theoretically port it out of Supabase for AWS to reduce costs.

PS: As of today, Lovable has backend capabilities in beta, so you may not need Supabase as much when you read this.

Claude, the UI designer

Whenever I needed UI designs, I would brief Claude. It can write and render code on the chat interface. Lovable-designed screens were often ultra-generic. To bypass that blandness, a PM friend of mine gave me the hint to send a screenshot of something that has a similar vibe to what you want, so Lovable can get inspiration from.

What is possible to build?

If it runs on the browser, you can likely build it.

Lovable excels particularly with CRUD.

Things that depend on a lot of fine UX are tricky, but can be built too. For example, I've built a simple roadmap management tool without all the bloat of pricey tools:

There are many real examples on the Lovable's Launched website.

Can non-technical people build with AI?

It depends on what you call “build”.

If by “build”, you mean simple prototypes and internal tools, then yes. But production grade? Probably not yet.

Emphasis on the “yet”, as these things are moving at an insane pace.

Think of the current vibe coding tools as a very junior developer who has an outstanding knowledge of code syntax and can do so at breakneck speed, but has terrible judgment and taste. Lovable, and any other coding agent, gets easily confused, enters weird rabbit holes, undoes what it just did to fix a bug, duplicates functions that already exist elsewhere, etc. As a non-technical PM who can barely write a for loop without Stack Overflow ChatGPT, if I can notice this, I only wonder the chill a real engineer feels when exploring a 100% vibe-coded repository.

All of this means that you have to guide the tool to make sensible choices. If you are 100% non-technical, it will be challenging to guide the AI in making the necessary software architecture choices.

That said, the first frontier is already within reach: replace quirky internal things that feel like they should be software, but are currently a spreadsheet.

Lesson #1: Treat it like a software development intern

Write PRDs, user stories with acceptance criteria, show screens, flash out interactions… just like you would with a real software engineer. You can’t just say “build a to-do list app”. That’s not how it works with engineers, that’s not how it works with AI.

I often used Claude or ChatGPT to help me write the PRDs and prompts. I also liked it to be structured like this:

# Goal
What you want to achieve with the change.

# Context
Describe all the stuff that the AI should know, like interactions, decisions it should make, etc.

# Constraints
Instructions it should comply with — more on that later.

Lesson #2: Images are really helpful

Images with the UI and interactions and diagrams are super helpful. Lovable seems to thrive on it.

For UI design, I use Claude a lot.

Lesson #3: Small iterations will get you faster to the goal

Big changes confuse the AI. Instead of asking for a complete feature, I learned to work in tiny increments: get the UI structure right, then add record creation, then editing, then deletion. One piece at a time. Again, just like you would with human developers.

Lesson #4: Use Clean Architecture

If I leave Lovable to its own devices, this is the software architecture it will create:

It might technically work, but every time you make a change, all hell breaks loose, and everything, including unrelated things, breaks.

But as a non-engineer, how can you help it create something more sensible?

The hack I found was to use Uncle Bob as a persona. I usually add something like this to my prompt constraints:

• You are Uncle Bob, always plan and implement clean architecture, SOLID, DRY, and other best system design practices.​

• Do not hack your way into changes. Analyze the change and the current code, refactor/start from scratch if that would make the system design more robust, maintainable, and easy to change in the future.​

• Don’t make unnecessary or unrelated changes to achieve the goal, unless they would improve the system design to achieve the goal.

• Don’t make unrelated changes to UI, UX, functionality, or behaviors. ​

• Remember to delete unused or deprecated code.​

• Avoid making things “backward compatible" because this is often a cop-out mechanism for a system that is not behaving 100% of the time as it should.

PS: Uncle Bob wrote one of the most influential software development books, “Clean Code: A Handbook of Agile Software Craftsmanship" (2008)”, and was the one who formalized the SOLID principles in software engineering.

This will not ensure anything, as LLMs tend to lie (“sure sure, of course I used the SOLID principles”). But at least it is more likely they will create a better foundation than a house of cards imagined by Salvador Dali with dementia.

Lesson #5: Refactor when asked to

As files get larger, Lovable will prompt to refactor (usually just breaking down a large file into smaller files). This is crucial. Always do it.

But… always test the before and after, because Lovable can destroy functionality by doing that, including changing completely unrelated things, like how the UI looks.

Lesson #6: Start with chat mode for most changes

Lovable has a builder mode and a chat mode. In builder mode, you prompt, and it writes code, one-shotting it. This often will go wrong. The best approach I found was to use chat mode. In chat mode, it doesn’t change the code, so you can use it to discuss changes. Yes, you pay for it, but believe me, you will use fewer credits this way than trying to fix the errors it causes by one-shotting the wrong thing.

In chat mode, I ask for it to make a plan and to ask clarification questions.

I also highly recommend using chat mode to identify the root causes of bugs. If you don’t do this, it will just pick a random vector and keep doubling down on it every time you give feedback that the bug is still there.

Lesson #7: Clear the cache to test

Sometimes you make a change, then you try to test it, and… nothing changed. More often than not I found that the browser had cached the old version of the system.

Go to the browser’s dev tools and clear the cache:

PS: Spengler educated me that there is a much simpler way of doing this. Go to the “Network” tab and click to “disable cache”.

Lesson #8: Use verbose logging for debugging

Lovable will do a very poor job at debugging if you just give the bug effects you are seeing. Ask it to add logs on the buggy feature and then paste it back to it for debugging.

Sometimes I did this with ChatGPT too, but I found the current version of Lovable is performing better and I need to do this less and less with another LLM. A recommendation I got, which I haven't tested yet, was to use ChatGPT o3 with deep research since it can access the same GitHub repo. Then take the instructions from ChatGPT and paste them to Lovable in Chat mode.

Lesson #9: Use Given/When/Then for debugging

A useful format to describe problems and desired states:

# Problem: impossible to select a team with the keyboard in the empty team select field

## Current behavior
GIVEN the team select modal is open and no team is currently selected on the input,
WHEN a team is selected through keyboard arrow navigation + enter,
THEN the team is not selected in the team input, and the team input remains empty.

# Desired behavior
GIVEN the team select modal is open and no team is currently selected on the input,
WHEN a team is selected through keyboard arrow navigation + enter,
THEN the team is selected in the team input.

Lesson #10: Revert to a previous working version

Contrary to human software engineering, writing code is the cheapest part of the process. Don’t be afraid to throw code away, restore the latest working version, and start again. It’s much cheaper than staying in the bug death spiral:

One pattern I use is this:

1. Code changes are made.

2. I test the changes. If I am happy with how it went (e.g. it’s working exactly as intended), I save that commit to history (the little flag by the side of the change).

3. If I keep changing things and struggle to get it right, I go back to the latest saved commit in my history and restore it. Then I start again, this time with more knowledge about potential issues, which leads me to change my prompt accordingly.

The impact of vibe-coding on product development

When writing code becomes the cheap part, with AI writing it without the need for technical expertise, some might think that software engineers will vanish. There are even some accounts of teams asking for a higher ratio of PMs vs engineers, and not only one person.

But my take is quite the opposite: engineers will likely take on some product management responsibilities, and product managers and UX Designers will need to learn some engineering to be able to ship independently. In a way, we are transitioning from a process where many things required discovery to one where they can be more easily tested and iterated in production. In a sense, many experiments that were discarded could be released simply because the coding part becomes much faster. So vibe coding will compete a lot with "not doing", from a jobs-to-be-done point of view.

If you are a product person, what are you waiting for? Start building. If you don’t get used to these, you might find yourself in a tough spot in the future.

Leave in the comments what you always wanted to build, but didn’t have the resources until now.

If you found this useful, smash the like button and share it with other product people who are curious about AI tools. It's a huge help to me (and might save them from making the same mistakes I did).

How often should you do a formal performance assessment?

The company decides on the frequency of the formal process. Usually, it's once per year or semester. If it is annual, I like to run an informal version of the formal process in the middle of the period.

Important: that's not how often you should give feedback to your reports. You should give them constant feedback, either praising or correcting the course. If a report goes without your feedback for over a month, you are doing it wrong. More here:

Performance assessment must be in writing. Period.

Writing forces clarity. You can't hide behind vague statements or diplomatic language when you write something down. Or, If you do, it will be plain obvious. You must be precise about what's working and what isn't.

Writing creates a shared understanding. Both you and your direct report can refer to the document, eliminating the "but I thought you meant..." conversations.

Writing serves as documentation. This helps track progress over time and, let's be honest, covers your back if things go south.

But how do you write a good performance assessment? The best I have seen is composed of these things:

1. Self-assessment.

2. 360-degree feedback.

3. Manager's feedback.

4. Manager's clear expectations for the next X period.

1. Self-assessment

Before any input from me, I want the direct report to reflect on their performance. This will either inform me of (often positive) things I was unaware of or prepare me to pay extra attention when there are significant perception gaps.

How I do this is usually asking the report to evaluate themselves on the PM competence model the company uses, always asking for them to justify their answers with concrete examples. If you don't have a competence model yet, just the normal “what you did good at” and “what you could improve at” should be ok.

2. 360-degree feedback

It's often hard to judge a PM's performance beyond what the team achieved because we, the managers, are often not in the room when they are working with stakeholders and their teams. That's why it's vital to ask for feedback from those who are most often working with them, the popular 360-degree feedback.

Gather feedback from people working closely with your direct report. This includes peers, stakeholders, and team members. It's helpful to ask your direct report for suggestions. But be critical of their proposal, as some people will only give names that would say nice things.

Once chosen, I give those people just two prompts:

1. [Name of the person] did great at:

2. [Name of the person] should improve at:

I always add to that briefing:

Try to make it specific enough so the feedback is easier to understand.
BAD EXAMPLE: [name of the person] is a great communicator (this is bad because it's hard to know what it means).
GOOD EXAMPLE: [name of the person] communication skills really helped the team when we were discussing the tradeoffs of X and Y, because she listened to both sides of the argument and made the right questions about which assumptions each side had. (A concrete situation and what she did makes it easier to understand).

I usually don't do this anonymously. I offer the person the option to anonymize the feedback if they want, but I know who gave which feedback. This is useful because I can ping people who haven't replied yet. Also, I can ask follow-up questions if the feedback is unclear.

In the past, I did some categorization of the feedback, too. This takes a long time, though. But now, with LLMs, it's pretty simple: you feed your PM competence model to Claude (or whichever LLM you use), and then you feed the feedback. You then prompt it with something like this:

I want to categorize the feedback my direct report got against the competences we have in the company.

In the attached Word document, there are 68 feedback quotes to my direct report. In the attached CSV, there is a list of product manager's competencies with the name of the competence and a short description.

I want you to:

1. Put the 68 quotes on a table format under a column named "feedback", each complete quote is a different cell.

2. Add a new column called "positive or constructive". Categorize the feedback as positive or constructive. They are already separated by this in the document, so it should be easy.

3. Add a new column to the table called "best competence fit", where you will list only one competence that the quote is most related to. Use the descriptions in the CSV to be sure of the best fit.

Take particular care to:

1. Don't forget any quote. All 68 need to be there. No more, no less.

2. Quotes with sub items (such as examples) need to be all under the same quote cell.

Add the feedback to the performance review document.

To make it easier to consume, you can also add a chart with the count of feedback in each competence, split by positive vs negative:

3. Manager's feedback

Here is what you decide to emphasize as a leader. You may use the 360-degree feedback to color it, but have examples of your own prepared (or you are likely being lazy, leaving the development of your report to other people's opinions). You should be clear about what you value on the PM (what they should keep doing) and what they should improve.

Especially on the constructive part, I like to list only what is crucial to taking the PM to the next level, not everything. People tend to focus on improving something, but often, they focus on the nice-to-haves instead of the must-haves. I don't give them this option; I only list the must-focus items.

4. Manager's clear expectations

This is where most performance management processes fall apart. Managers expect people to magically know the answer to how to improve. Lots of times, they can do that, but also often not: if they knew, they would be doing it.

Don't stop at identifying problems. Create clear, actionable paths to improvement. For any point mentioned in the item above, I like to have clear expectations about the improvement I want. E.g.:

What I want to see in the next 4 weeks on the topic “clear team direction”:

1. A clear, measurable, and outcome-oriented next quarter's goal. Not five. Just one or two.

2. One or two opportunities/problems your team will address to achieve the next quarter's goal.

3. A roadmap of solution hypotheses for the next quarter. Each should be linked to one opportunity (from above).

4. All of the above in a single, short (less than 3 pages), and well-written document. Don’t ChatGPT it; or it will be long and terrible.

Here's what a good improvement plan looks like:

1. Time-bound expectations. Don't just say "improve communication." Say "In the next 4 weeks, I expect to see..."

2. Concrete changes. List specific behaviors that need to change. For instance: "Every meeting should have a clear agenda shared 24 hours in advance and documented decisions/action items shared within 24 hours after."

3. Clear metrics. How will you know if the improvement happened? For example: "By the end of Q1, you should have shipped at least three customer-facing improvements, no matter how small."

4. Regular check-ins. Set specific times to review progress. I recommend weekly for critical improvements.

The golden rule: no surprises

Here's the most important principle: If anything in your performance assessment surprises your direct report, you have failed as a leader.

Your job is to give feedback early and often. The performance assessment should summarize conversations you've already had, not a bombshell of new information.

Closing thoughts

Performance management isn't complicated, but it is hard work. It requires discipline to give regular feedback, courage to have difficult conversations early, and clarity to set concrete expectations.

But here's the thing: your job as a leader is to develop your people. Get this right, and you'll build a team that can handle whatever challenges come their way.

What are your experiences with performance management? What works for you? Let me know in the comments.

Thanks for reading Product Leadership IO! Subscribe for free to receive new posts every once in a blue moon (ok, 3-5 weeks).

Subscribe now

PS: If you found this article useful, please smash that "like" button and share it with other leaders who might benefit from it.

Even though I have been relapsing with posting for the last months, my goal with it is still the same:

Write about real-life product leadership (not how Google supposedly does it). This is valuable to me because helping others grow is deeply satisfying. It is also much easier on my calendar than mentoring. Writing also helps me learn, as it clears my thoughts. Finally, I want to develop my brand around product leadership.

When I launched Product Leadership, my ambition was to reach 1,000 subscribers. There is a long way to go; I have 290 subscribers while writing this. If you haven't subscribed yet, you can contribute to the goal:

Subscribe now

Most popular articles

1. 🔥Hot take: Product Management isn't hard (1.86k views). The PM's job is straightforward. PMs need to deliver business results through products that customers love. Yet, most companies make it unreasonably hard to do the job well.

2. Your company strategy is sh*t (1.78k views). What most companies pose as strategy is everything but. I clarify company strategy and how to build one in practice, with an example about validating it.

3. Product operating model assessment template (1.69k views). I read Marty Cagan's excellent Transformed book and transformed it into an assessment template. This should help any company improve its product development practices.

4. How to develop high-performing PMs, a no BS practical guide (1.12k views). It is the most critical responsibility of every people manager to develop the skills of their people. Yet, so many leaders don't do the basics.

5. The Founder Mode vs. Management Mode debacle (733 views) is a cautionary tale for founders who think they are Steve Jobs. It also explains how to put “founder's mode” into practice without missing the point.

My personal favorites

1. How to not suck at 1:1 meetings (498 views). I have participated in a fair share of useless one-on-one meetings. Do yourself and your direct reports a favor by reading this.

2. Spreadsheet prioritization framework quackery (442 views). Prioritization frameworks are the homeopathy of the PM world – seemingly scientific, but ultimately not. While an interesting exercise, spreadsheets cannot prioritize for you.

3. Good Product Leader/Bad Product Leader (356 views). Eventually, every product writer will write a take on the seminal Good PM/Bad PM by Ben Horowitz. At least mine is about product leaders.

4. The leader's user manual (325 views). How to write your readme file to set expectations with your reports. I've included my (real) example, which always gets me praise when joining a new company.

5. How to craft a product strategy and put it into practice (822 views). Step-by-step and with examples.

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, other product leaders too).

Subscribe for free to never miss a post:

Subscribe now

This post is public, so feel free to share and forward it:

Share

And like “MVP,” it will be wildly misused until it loses its real meaning.

Subscribe now

Founder Mode vs Management Mode

The center of Paul Graham’s article is that there are two ways to run a company: Founder Mode and Management Mode. The former argued to be more effective than the latter. But most founders, as they scale their company, were advised to adopt Management Mode, which was disastrous for the business.

The “misguided” advice can be summarized by “hire great people and let them work”. And the article adds to that advice:

(…) what this often turns out to mean is: hire professional fakers and let them drive the company into the ground.

Then he closes the article with the example of Steve Jobs vs John Scully as Apple’s CEO.

How Founder Mode will be misused

Just because Steve Jobs was brilliant, he is often given a pass for being an a**hole at times. Then some founders justify their abrasiveness (unpaired with Jobs’ consumer insight brilliance) by using him as an example, not realizing the part they needed to emulate was not Job’s a**hole-ness.

The same will happen with Founder Mode.

Founders will justify micromanaging and decision-making centralization by saying it’s Founder Mode. This will happen even in areas where they are infinitely less brilliant than the person who should be running the initiative.

I have a real example of this from my career:

I was once a product leader at a company whose CEO was the main driving force behind product initiative prioritization. He was solidly in Founder Mode regarding the product. The end result was that the product's initial vision was brilliant, but having passed that, it was underperforming: Roadmap items rarely delivered on the business's goals. Then, we created a new team in a domain that the CEO didn’t have a clue about, so he allowed us to figure out what we could do. The result was that we achieved insanely high results. That led to the product function earning more trust, with other teams operating more independently, which, in turn, started bringing better results.

In defense of Founder Mode (but not what you are thinking)

Until now, you might have thought I was advocating against Founder Mode.

I am not.

Founder Mode and Management Mode is a flawed dichotomy, though.

What is being called Founder Mode is a set of conditions and behaviors that are more often present or easier to display as founders. But a company doesn’t need to be founder-led to have it.

Instead of learning the (easy) lesson of “let’s micromanage everything and call it Founder Mode,” we should learn the (hard) lessons:

1. Risk-taking appetite and acceptance of failure

As the startup failure rate is so high, founders are more risk-takers by definition. As a company scales, it starts to bring “adult supervision.” Professional managers, especially those with extensive careers in massive companies (as scale-ups often prefer to hire), have a lower risk threshold. Not only that, but they are employees, which means they are more easily fireable than a founder.

Shocker: No one wants to get fired.

Professional managers prioritize low-risk initiatives. They don’t want to be blamed for failures, especially early on in their tenure. They start thinking more about ROI (which inevitably passes through the cost of doing something) than raw impact. This inevitably pulls things down into the lowest and safest denominator of low risk and low impact. It’s managing the day-to-day and incremental improvements mode.

Do this exercise: Of all the roadmap items in your company right now, how many would be in the low-risk and low-impact corner?

If most things are “do or die,” professional managers will focus on safe bets. If failure is not an option, guess what? Risk-taking won’t be an option either. Companies need to incentivize bold bets by being okay with failure and learning fast. Disruptive things often fail.

Look at Google. Remember when they launched Gmail with 1 GB free storage (vs. the competitors’ 10MB), Maps, Wave (which was the foundation for Docs), Drive, Orkut and Plus? Look at them now. They invented the transformers technology that underpin the AI revolution we live today and did nothing besides safe bets. They had a human-sounding AI demo (Duplex) in 2018 (!!!!) and did jack shit with that:

2. Inspected trust

The best managers don’t want to be micromanagers. They want to empower and trust their team. But here is an important lesson:

Trust isn’t a management technique.

You absolutely should trust your team, but it should not be unquestioning trust. You shouldn't avoid inspecting the work and diving deep where necessary. You can trust someone while doing your independent investigation of the facts.

3. First-team mentality and breaking down silos.

Another trait founders have is an extreme unwillingness to stay in their lane. It’s their company. They don’t care about the organizational structure. If they see something that needs fixing, they skip management levels if necessary.

On the other hand, professional managers don’t want others sniffing their pants, so they don’t go about doing it to others. They are specialists, not generalists like the founders who needed to write code AND take out the trash. This leads to siloing. These siloed sub-organizations optimize for their silo instead of optimizing for the company.

To break this up, the company needs to develop a first-team mentality with the executive team: they are executives for the company first, then second leaders of their functions.

You don’t need to be a founder to develop that mentality; you just have to be a good leader and manager.

4. Stop hiring fakers

When hiring executives, the so-called “adult supervision,” the founders almost always know less about the function than the people they hire. However, this means that they are not skilled enough to fully understand the competence of who they are hiring, which leads to hiring phonies and bozos.

I don’t have a magic formula to stop this from happening, but some recommendations to hire better:

1. Is the company size they are most effective in similar to what you will be in 12 months or so? Too big of a gap will result in hardship for everyone.

2. Is there a leader in the function, for example, outside of the company, who you trust and who could help with the hiring assessment?

3. Can you promote someone from within, even if it takes a little more time to get up to speed? You could always hire the trusted leader mentioned above to be a coach.

4. Don’t tune your hiring process for the absence of weaknesses, hire for the fantastic strengths your company needs the most.

Closing thoughts

I hope this shines a little light on the Founder Mode discussion, especially since it is not about being a founder or a micromanager but about:

1. Increasing the risk-taking appetite and acceptance of failure;

2. Trusting, but verifying;

3. Breaking down silos and having a first-team mentality;

4. Stop hiring phonies.

Subscribe now

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, to other product leaders.

A lot of movement doesn’t necessarily mean significant progress, though. A full calendar might make one feel important, but it is rarely a sign of effectiveness.

Subscribe now

Time is a leader’s most scarce and finite resource

“Time management” is a whole discipline. All sorts of freaky effectiveness gurus tell you about waking up at 4 am to exercise and whatnot. But “time management” is a funny name. Because time is unmanageable.

You can’t make time run slower or increase it. The day has just so many hours for everyone. You can’t manage time or earn more of it. You can only manage how you spend it.

Time is the ultimate non-renewable resource. Once spent, there is no going back.

And it is odd that product leaders, so attuned to the prioritization in their products, end up with calendars like this:

Given free rein, all leaders’ calendars in a sufficiently large organization will always drift toward being insanely full. Leaders have to take it back. Actively and periodically.

Calendar Audit technique to the rescue (of time)

I like the LNO Framework proposed by . The short version is that you have to separate your tasks into 3 buckets: Leverage (10x return over effort), Neutral (1x), and Overhead (<1x). I do something similar with my weekly Watchtower Reflection, so I focus on the most important things I want to achieve the following week.

However, no plan survives the contact with stakeholders.

Instead of just looking forward (planning), you must also look back (reflection) on how you used your time.

To that end, I picked up the “Calendar Audit” technique from an old Peter Drucker book called “The Effective Executive.” It’s from the 1960s, so the language is very dated—case in point, I am the least woke person you can find, and I got pretty bothered by how he uses “men” to refer to “people” or “executives” throughout the book.

Drucker suggests a straightforward process: audit your calendar. Here's how you can do it:

1. Track Your Time: For a few weeks, record everything you do. Yes, everything. Meetings, emails, coffee breaks—capture it all. You might be surprised at where your time actually goes.

2. Analyze the Data: Once you've got a good amount of data, sit down and analyze it. Look for patterns. Are there recurring meetings that don't add value? Tasks that could be delegated? Identify the time-wasters.

3. Make Changes: Armed with your newfound insights, it's time to act. Cut out the unnecessary meetings. Delegate tasks that don't require your expertise. Block out time for deep work. This isn't a one-time fix; it's an ongoing process. Regularly revisit your calendar to ensure you're staying on track.

By auditing your calendar, you can free up time for what matters. It's not just about cutting back; it's about making deliberate choices that align with your goals.

Prioritize your time spent like you prioritize your product.
(Unless you live in a product development hell where all prioritization happens by HiPPoing and the loudest stakeholder/client).

Subscribe now

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, to other product leaders.

One caveat: this is not an excuse to be an a**hole. It shouldn’t be, “Oh, it’s in my manual; deal with it.” It should not be an excuse for managers ’ bad behavior. It’s an alignment tool and should help direct reports to collaborate more effectively with you.

Subscribe now

What to include in the leader’s user manual

These are the typical things one would include:

1. Intro

2. Communication preferences

3. Working hours

4. Leadership style

5. Expectations

6. Any extra stuff or quirks

Here is one example from when I worked as the head of product at a fintech: Sergio’s user manual.

01. Intro

Start by briefly explaining the user manual and why you created it.

Example:

This document is a guide to help you understand my working style, preferences, and expectations. My goal is to make our collaboration smoother and more effective by being transparent about how I operate.

02. Communication preferences

Detail how you prefer to communicate. Do you like quick Slack messages, or do you prefer detailed emails? Do you like face-to-face conversations, or do you thrive in written communication? If you challenge something, does it mean you are against it or you are just going for a devil’s advocate style? Do you have communication quirks?

Example:

1. Async > sync: when it makes sense, I prefer async comms (e.g. having pre-reads, video to watch at 2x, Slack message, etc). Long discussions are better to finish in a sync meeting though.

2. Slack is not sync: I do not expect an immediate response when I message you - unless I say it is urgent. But if you take more than a day, it's nice to say something like "saw it, will reply on X date" or just  👀.

3. Default to public: unless it's private, say what you have to say in the most relevant Slack channel, not in DMs.

4. Start with the why: if I don't understand why you are doing something, I won't care much about it.

5. Answering questions: when I ask a question, try first to answer it and then explain later. If you explain first, I might not listen well because I am thinking "where is the answer to my question?"

6. Transparency: I am super transparent and expect you to be too. Don't BS or hide stuff. If it is not a secret (e.g. a business thing I am not allowed to tell you), I won't hide it from you. Communicate early and often.

7. I hate email: if you want to annoy me, send me emails when a Slack message would do.

8. You can change meeting times: All my meetings have a "guests can modify event." If something comes up, you can just look at my calendar and move the meeting yourself. I will do the same.

03. Working hours

Clarify your working hours and availability. This will help your team know when they can reach you and when you need uninterrupted time. This is especially relevant for teams with distributed people.

Example:

I typically work from 9 AM to 5 PM Berlin time. I reserve the first hour of my day for focused work, so I might not respond to messages until after 10 AM.

I have a small kid, so 5 PM to 8 PM Berlin time is her time and I am generally completely unavailable.

04. Leadership style

Explain your leadership style. Are you hands-on, or do you prefer to give your team more autonomy? How do you handle decision-making and problem-solving?

Example:

1. I care, but I challenge: every leader should be measured by their weakest follower. A lot of my job is to help you grow. I really care about your well-being and career, but that doesn't mean I will be soft. I will give you hard feedback, and I expect that you offer it back too.

2. 1:1s are yours: the follower is the owner of the 1:1. This means you are responsible for making the most of it. Add your agenda items to our shared Notion (if you don't, I will assume you came unprepared and are wasting both our times). I will use whatever time is left over for my agenda items. If no time is left over, I might schedule a special meeting to cover my points.

3. You are in charge of your development and career. I see my job as supporting you in your growth, but I can't do it for you. The heavy lifting comes from you.

05. Expectations

Outline what you expect from your team members. This could include work quality, communication standards, or how you handle deadlines. If you manage individual contributors and leaders, you can have different expectations for each group.

Example:

1. Measure and report product changes' outcomes: as a team, you need to deliver. But I am not interested in your output, I am interested in the outcomes your team achieves. Measure what your product changes should achieve and proactively report if you have achieved them and what you have learned.

2. Talk to users often: if you are a PM and you haven't interacted with a real user in more than 2 weeks, you are not doing your job to the fullest. 

3. Number of iterations > quality of iterations: don't aim for perfection, aim for increasing the speed of feedback and iteration. This will lead to better product outcomes.

4. Validate hypotheses, not ideas: the best way to increase iteration speed is not to validate a whole idea, but to decompose it to the riskiest assumptions and validate those.

5. Balance the art AND the science of PMing: I am very data-driven, but if you only lean on data (the science part) you will only optimize things to a local maximum. You also will be too slow (100% certainty is too expensive most of the time). But if you rely too much on intuition (the art), you will be more often wrong than not - and that's a lot of wasted resources. Try to be balanced.

06. Any extra stuff or quirks

Feel free to add any information that might help your team better understand you. This could be personal quirks, pet peeves, or anything else you think is relevant.

Closing thoughts

Creating a leader's user manual fosters transparency and builds a more cohesive team. It's not about being self-important or demanding; it's about ensuring everyone is on the same page and can work together effectively.

Sharing your working style and preferences gives your team the tools they need to interact with you more effectively. In turn, this can lead to better communication, fewer misunderstandings, and a more harmonious work environment.

So, take some time to reflect on how you work best and put it down on paper. Share it with your team and encourage them to do the same. You might be surprised at how much smoother things run when everyone knows the game's rules.

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, to other product leaders.

High-performing individuals do not (necessarily) lead to great teams

From 2008 to 2010, I saw an organization go from almost bankruptcy to breaking its performance records. The critical difference was that the leadership team was almost entirely replaced. It might look like a clear-cut people problem: good leaders replaced bad ones.

That would be wrong, though.

Both leadership teams were composed of high achievers and strong individuals. The key difference was that the successful team, the one who saved the organization from certain doom, was a team, while the non-performing one was a group of individuals. On one, the team was consciously built to be high-performing, while on the other, it was left to form itself, which led to suboptimal results.

This article aims to help leaders build their teams properly to achieve high performance.

Characteristics of a high-performing team

Many authors explored team performance. Most say similar things with slightly different spins. This is a good indication that there are common characteristics for high-performing teams. It’s not pseudo-science.

For the last 20 years, I have evolved my own flavor of team performance characteristics. It’s loosely based on Patrick Lencioni's book The Five Dysfunctions of a Team, but a little different — as I picked up a thing or two in these last 20 years. The high-level characteristics are:

1. Clarity of team mission and purpose

2. Roles and responsibilities

3. Operating processes

4. Interpersonal relationships

5. Relationships with other teams

I will briefly discuss each, but if you just want to use the tool right now to assess your team’s health, go to the spreadsheet with all the details.

01. Clarity of team mission and purpose

You must know and agree on what you want to achieve as a team, how it is measured, what is not something you do, etc. All of this needs to be aligned with the overall organization, too.

Characteristics to evaluate:

1. The team mission is clear and all team members are committed to the mission

2. Team mission is aligned with the organization and product vision and strategy

3. The team sets clear and measurable outcomes early and well

4. Objectives and goals are clear to everyone on the team

In my example of the performing and non-performing teams, it was quite clear for the performing team that they were facing an existential threat and that cash flow was king, while the non-performing one didn’t instill this clear focus and had each member pulling in different directions.

02. Roles and responsibilities

Roles and responsibilities differ in cross-functional teams. Team members must agree on those roles, be competent at them, understand their intersections, and commit to the team goals even when their role negatively affects them.

Characteristics to evaluate:

1. Individuals' roles and responsibilities in the team are clear

2. Team members know what their peers are working on and how they contribute to the collective good of the team

3. Interdependencies within the team are clear

4. Every team member is committed to the team's objectives and goals, even if it negatively affects their personal goals

5. The team has people with the right talents to do what has to be done

6. Talent gaps are known to team members and the team has identified how to access the required talent

7. The right people are assigned to the right tasks

8. The team has the right leadership to achieve the required outcomes

In my example, the high-performing team had so much commitment that, for several months, two individuals of the team chose not to be paid (!) and lived off their own savings (!!)—the alternative was leaving the organization. It’s extreme, and I don’t recommend it, but I know they don’t regret it.

While on the non-performing team, some members would defend their own turfs to the detriment of the whole.

03. Operating processes

How the team works and how it uses its resources.

Characteristics to evaluate:

1. The team sets priorities while at the same time retaining flexibility

2. The team has tangible, visible, and meaningful measures to assess progress and performance

3. The team uses robust and timely team decision-making processes

4. The team learns from successes and failures

5. The team uses resources well (no wastage and no spinning wheels)

6. Team processes are “tight” and focused on team effectiveness and efficiency

7. Team ground rules are agreed upon and maintained

8. Meetings have clear purpose, agenda, and outputs

9. The team ends discussions with clear and specific decisions, resolutions and calls to action

10. The team's decisions, resolutions and calls to action get done promptly and are never forgotten or ignored

11. The team's meetings involve the right people

There were so many issues with this in the non-performing team, not the least of which was that ground rules were never agreed upon. This led to four of the six team members being romantically involved, which freaked out the team leader, who was very against this sort of thing. This was a frequent source of strain between team members and the leader.

04. Interpersonal relationships

It is all about understanding team members as people, building trust, etc.

Characteristics to evaluate:

1. All team members value one another’s strengths and accept each other’s limitations

2. All team members give positive and negative feedback to one another

3. All team members are comfortable discussing their weaknesses and mistakes.

4. All team members ask for help without hesitation

5. All team members know about one another's personal lives and are comfortable discussing them

6. All team members quickly and genuinely apologize to one another when they say or do something inappropriate or possibly damaging to the team

7. Unacceptable team and individual behaviour is called early

8. Team members hold each other mutually accountable for outcomes

9. Communication inside the team is open, honest and complete

10. Team members earn trust by doing what they promise

11. People collaborate rather than compete with one another

12. All team members are slow to seek credit for their own contributions, but quick to point out those of others

On the performing team, we were so close that we developed a deep friendship, with people still in touch after 15 years. For example, 2 of the 5 team members crossed the Atlantic to attend my wedding.

On the non-performing team, some interpersonal tensions were quite hard to reconcile.

05. Relationships with other teams

It would be beautiful if a high-performing team just depended on itself to perform, but in most organizations, there will be a myriad of stakeholders and other teams that impact the work.

Characteristics to evaluate:

1. Interdependencies/interfaces between teams are negotiated and clearly understood

2. Information is willingly shared between teams in a timely manner

3. Teams break down barriers to enable the respective teams to achieve their goals

4. Teams operate in a spirit of collaboration, not competition

5. The team is not blocked by other teams to achieve its objectives and goals

In my experience, this one is usually the hardest one to change when it is going badly.

How to use the product development team health check assessment

There are many ways of using it, for example, as a leader's reflection tool on what to improve in their team or as an anonymous form for later discussion. However, from my experience, what works best is the entire team getting together, reading a single statement, and then voting simultaneously if they think it's 1, 2, 3, or 4. When there are different perceptions, ask the people with the most extreme answers to explain why they voted like this. Finally, you can re-vote or have a group consensus on the average score.

After the assessment, pick a few items with the worst scores and discuss ideas for improving them. Then, commit to actions with a clear responsibility and deadline.

Re-run the assessment after some time (I prefer to do it once per quarter).

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, to other product leaders.

It's your loss.

Don't we believe cross-functional teams trump specialists working alone in silos? Innovation thrives on diversity. We lose a lot of diverse perspectives by brainstorming solution ideas with only the product development team responsible for addressing a problem.

That's why I like to use a special way of generating ideas for important problems. I call it the “Idea Avalanche.”

Subscribe now

What is the Idea Avalance

It's just a fancy way of saying async brainstorming, which involves a large group of people and is often open to anyone in the company.

Cross-functional collaboration is widely recognized as best practice in many business areas, not the least in product development. With brainstorming, nothing is more cross-functional than getting the entire company involved.

Building Context

Of course, just asking for ideas without providing the right context leads to suboptimal results. People need to understand the problem clearly to offer valuable suggestions. This doesn’t mean overwhelming them with hours of reading material; context should be concise and prioritized.

In my experience, a short video—less than five minutes—highlighting key insights about the problem works wonders. Make it easily accessible and include links to more detailed documentation for those who want to dive deeper. This ensures everyone is on the same page without demanding too much time.

Recruiting participants

Once the context is well explained, share it in wide forums (e.g., a company-wide Slack channel) and invite participation.

It’s also crucial to set clear criteria for evaluating ideas by sharing a clear goal you want to achieve. This helps assess which suggestions will most likely solve the problem effectively, keeping the brainstorming more focused.

Executing the Idea Avalanche

I find that asynchronous brainstorming has significant advantages over synchronous methods. Research shows that asynchronous work can boost creativity, especially for those in lower positions who might feel less comfortable speaking up in live settings. Plus, asynchronous brainstorming can involve way more people—potentially thousands—compared to the limitations of a live session.

I prefer a simple way to contribute anonymously, such as a Google Form with just one text input and no need to log in.

Encourage everyone to generate as many ideas as possible, emphasizing that no idea is too wild at this stage.

Also, remember to set a deadline for contributing—nothing too far in the future. One or two days should be enough. That's probably less than the number of days you would need to book a sync brainstorming meeting with the more relevant stakeholders.

Filtering and evaluating ideas

After gathering many ideas, the next step is to filter them. Expect a mix of high-quality suggestions, random thoughts, and some that will be indecipherable. This I prefer to do in a small group, like the product development team.

Here’s how to handle this phase:

• Remove the trash: Some ideas will not impact the goal at all, some will solve different problems, some will be unintelligible, etc. Just remove them.

• Group similar ideas: Combine very similar suggestions.

• Voting: Have the product development team vote on the ideas to identify the most promising ones.

• Selection: Choose a few top ideas to explore further. These ideas should be fleshed out and de-risked before moving forward.

Closing thoughts

The Idea Avalanche, or simply async brainstorming, is the best way to gather a diverse range of ideas quickly. We tap into a vast reservoir of creativity and insight by inviting the entire company to participate. This approach leads to better solutions and fosters a culture of collaboration and innovation. Remember, great ideas can come from anywhere—our job as product leaders is to create the conditions that let these ideas flourish.

Liked? Subscribe, smash the like button, share with friends… you know the drill. This is a tremendous help to me (and, hopefully, to other product leaders).

Subscribe now

“Product management is hard” is a common trope. But here is the deal: The PM's job is straightforward. PMs need to deliver business results through products that customers love. The mechanisms for understanding customers’ problems, coming up with solutions, and validating those are not rocket science (unless you work at SpaceX). Product delivery is even less so after the release of the Agile Manifesto in 2001 (!), and all the amazing tech infrastructure and tooling we have nowadays.

Yet, Product Management feels unreasonably hard to do well. In most companies where it happens, good product management occurs despite, not because of, the company's processes and systems. PMs often do their jobs feeling like an anchor is tied to their ankles.

In other words, most companies make doing good work as a PM unreasonably hard.

Here are a few common things companies do that make good product management very hard:

1. Bad direction

It's the first because it is so prevalent, even in otherwise good companies: either there is no vision and/or strategy, or they are very fluffy and ambiguous to the point that they are not useful in making decisions. Other signs of bad direction are trying to be all things to all people or the classic “the strategy is to grow revenue by X” without any indication about the choices being made for that to happen.

This leads to conflicting priorities, with product teams being pulled in multiple directions by the loudest stakeholder or the latest burning fire. The result is a product that doesn't know what it should be to whom, which is not good for anyone — including the business.

What to do instead: Ensure there is a clear company and product vision and strategy. Evangelize that at every opportunity you can. As a leader, you have to help teams say “no” to distractions.

2. Top-down feature mandates

Closely related to “bad direction,” leaders delegate features for the “tech teams” to build. PMs become order-takers and project managers. Product development teams stop serving customers to, instead, serve the business. Features are launched but with little business results. When they fail to move the needle, the leadership pushes for another round of top-down feature mandates—because, this time, it will work. We *just* need to build X.

Why does this, often called the “feature factory mode,” not work? Aren't the leaders the smartest and most competent people in the company?

Firstly, experience shows that such an approach leads to a low 20-30% success rate. This is because no idea survives the first contact with the customer, no matter how smart one is. The key is to learn and iterate fast—the best teams do anything between 15 to 30 iterations per week. Of course, if the team's goal is building a feature, they can't iterate effectively towards the business goal behind it.

What to do instead:

1. If you are a leader, delegate clear problems and goals to product teams (outcomes they need to achieve) and let them figure out how to tackle them best.

2. If you are an individual contributor, before committing to building it, ask the stakeholders what goal they want to achieve by building the feature. Before you start the work, record what the stakeholders thought would be achieved with the feature, and then after the launch, report on the expectation vs. the reality.

3. Long output-based roadmaps

Businesses crave certainty. They want long (6/12/24 months) roadmaps that detail what features will be delivered and when. The best quote I ever saw about these roadmaps comes from Drift's founder, David Cancel:

"Either I'm going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it's not, or by changing course and having lied to you."

Product teams know the roadmap is a complete fiction. It's our best guess at the time—and if we are doing our jobs well, our knowledge will be very different three months from now. The only certainty is that it won't play out like in the roadmap.

What to do instead: Businesses are not wrong in craving certainty. We just need to be clear about what can be certain and what is instead a Quixotic quest for unachievable certainty. There are many ways of doing this, but I recommend splitting a roadmap into a short-term (1-3 months) section, where features/outputs are listed together with what outcome they should impact. Further into the future, everything is expressed as problems/goals (outcomes). You can even sprinkle solution hypotheses for those, but people reading it must understand that they are hypotheses based on our current knowledge.

This way, the business can be more certain about planning (which goals/problems we are committing to tackling) without shackling itself to a list of features that will fail.

4. Discouraging discovery

Some businesses hate “discovery,” almost as a dirty word. It implies they don't know what they are doing, not to mention that leaders tend to believe they know what is necessary (see “top-down feature requests” above). At best, it is seen as a waste of time.

Leader: — Why are you wasting time? Just deliver feature XYZ. It's *obvious* XYZ will be a game-changer when released.

Narrator: — It was not a game-changer.

There are overt ways to discourage discovery (e.g., “Product teams are forbidden to talk directly to customers; you can talk with sales; they know our customers best”) and more subtle ways (e.g., “Is that what you discovered? I knew that already. It's obvious”).

To be sincere, it is not (only) companies to blame. Many product teams have no clue what they are actually “discovering” and how to go about it. They spin their wheels and/or spend too many resources (usually time) with little to show for.

What to do instead:

1. If your company is allergic to “discovery”, frame it as “risk mitigation”. Businesses love mitigating risk (see the love of certainty in “Long output-based roadmaps” above).

2. Do not test whole ideas. Test the riskiest assumptions underpinning them.

3. 100% certainty is too expensive. Instead of thinking about the perfect discovery and validation, ask yourself, “How could I have some evidence (not proof) that the assumption is true or false in less than one hour (or day)?” Cue to one of my favorite stories about fast validation:

The team at Google Glass had the hypothesis that the user interaction with the Glass would be through gestures akin to Tom Cruise's Minority Report:

To test this hypothesis, the team was going to build a prototype that would take 2 months to be ready. Tom Chi, then Google Glass PM, challenged the team to come up with a way to test that assumption “today”, instead of in 2 months. The team said it was not possible, it would take more than that just for the prototype to come from the workshop. But he kept pushing “how might we test this today?”

The team found a way: they used a computer connected to a projector, which in turn was connected to a rubber-band glove and a slide clicker. This way the user would have the feeling of changing the images on the screen with their hand movement. Half a dozen usability tests in, they were pretty sure that was not the way to go, because all the users complained of shoulder pains. It was just uncomfortable to the human anatomy to interact like that. Imagine if the team had taken 2 months to disprove that hypothesis instead of just one day? If they could do it with a hardware product, what is your excuse for taking a month to validate assumptions in software products?

5. Bad organizational structure

Another common way to hinder product management is using inefficient organizational structures. There are several anti-patterns I experienced firsthand:

1. Highly coupled teams. To deliver anything meaningful, teams depend on other teams. An example is dividing product development teams into classic front-end and back-end teams. This ensures no team can deliver meaningful things without the other, slowing everything down and leading to many alignment meetings. Another classic example is splitting it by platform (e.g., mobile team and desktop team), but with the same users using both platforms interchangeably (thus, with the same wants and needs).
   

2. Short-lived project teams. At some point in a startup's life, someone in power will be adamant that they had a great idea:
   
   “Listen to me, this is good. Engineers are our most expensive resource. Let's make the most out of them by creating a pool of engineers, and then we staff projects based on their needs. This way, we can always allocate our valuable engineers to the most promising things.”
   
   The idea could make sense if engineers were robots. In reality, every time a new team forms, the team must go through a “figure out how to work together” phase, which delays the start. If that is not enough, the company loses all the domain knowledge acquired by the team by dissolving it and placing it in a completely different set of challenges and code bases. Oh, talking about code base, how much do you think engineers will care about good code quality if they won't be responsible for touching the code again? The final nail is that this has all the same problems of “top-down feature mandates.”
   

3. Overlapping or unclear ownership. When two people might own the same decision-making scope, it's a recipe for many hours of back-and-forth meetings, false starts, and 180-degree turns.
   

4. Unbalanced influence between UX, Product, and Engineering. The most common is engineering or product having more decision-making power over the product trio (engineering, UX, and product). The other two perspectives are lost.

What to do instead: This is a hard one. Organization structures are hard, highly contextual, and full of trade-offs. The general recommendation is to build long-lived teams that own the full scope (not shared) AND the resources to deliver everything they want without coordinating with other teams. Also, make sure that the engineering, UX, and product functions have equivalent “voices” inside the company and that no one of the functions “rules” over the other.

6. Hard to get good data

Qualitative and quantitative data are important, and product development teams need unhindered and direct access to them. However, it's often very hard to talk to customers (e.g., there are no reliable mechanisms to recruit and interview them), and/or quantitative data is incomplete or nonexistent.

The harder it is to have good data, the more likely teams are to use lots of resources for discovery (leading to the “discouraging discovery” problem) or make most decisions using gut feeling.

What to do instead: Have good product analytics in place, such as Mixpanel or Amplitude. Invest in making it reliable and complete. Also, there should be a simple way for product teams to speak directly to customers quickly. It's not rocket science.

7. Constantly prioritize the business over customers

A company needs profits, but so many companies turn into “milking the cash-cow dry” organizations, constantly screwing up customers in favor of earning that extra decimal point of revenue. The focus becomes on internal metrics, not on delighting customers. Depending on the type of business, this can last a long time (hello, dominant marketplaces!), but it will eventually lead to the company's demise.

What to do instead: At least balance long-term sustainable gains with predatory short-term gains. Hopefully, the company is in it for the long run, so there is no point in alienating its customers. As a leader, you have to be clear that customers come first (in ways that work for the business). Doing something “because you can get away with it” is a losing proposition and needs to be discouraged by the leadership—not rewarded.

8. Bad leaders

Unfortunately, many organizations suffer from poor leadership that lacks an understanding of product management principles, fails to foster a learning culture, or does not provide coaching, mentoring, or constructive feedback.

What to do instead: reward and recognize great leaders, not good politicians. Have clear standards and principles leaders need to abide by.

9. Company-wide, rigid and cumbersome processes

In the search for The Right Way© to develop products, companies start implementing all sorts of processes. Suddenly, the process becomes a religion, and to fix a bug, one must write a 6-pager PR FAQ. The most annoying of these religions I ever encountered was “Shape Up,” which, in my opinion, is a glorified “top-down feature mandate” mixed with “short-lived project teams.” Thankfully, I've never had to work with SAFe.

What to do instead: think that every time you implement a company-wide process, a panda dies. Is this process you want to implement across the org absolutely necessary? Could it be just a good case practice, and instead, leaving teams free to adopt it when they see value in it?

Closing thoughts

In conclusion, product management itself is not inherently difficult. The biggest challenges arise from the organizational environments and outdated practices many PMs navigate. By addressing these common issues, companies can make product management great again — and achieve awesome business results.

Please subscribe and smash the “like” button if you found this article useful. If you know anyone who could benefit from it, share it with them or on your social media. This is a big help!

Alas, here I am, writing my take on the famous article, but with a spin on product leaders. You can call me a pretentious dork.

Subscribe now

A good product leader builds a product strategy for how to win based on a deep understanding of the market, the customers/users, the product, and the competition. Bad product leaders have a laundry list of projects and features to deliver.

Good product leaders evangelize the vision and strategy in written and spoken form. They ensure everyone understands the direction and the reasons behind it. They passionately advocate for the product and inspire others to share that enthusiasm. Bad product leaders complain that people are not aligned. They don’t take a written stance on the strategy.

Good product leaders focus the organization on the key challenges while also being clear about what not to focus on. A bad product leader complains that the competition is launching features faster and pressures teams to copy them. Bad product leaders have financial goals but no strategy for which levers to pull to achieve them.

Good product leaders delegate clear problems and objectives to development teams. Bad product leaders assign features to be built, then complain those features didn't reach the expected goals. A good product leader gives the team room and resources to tackle the delegated problems/objectives. Bad product leaders spread resources thinly to try to achieve everything, which results in not achieving anything. They complain about goals not being achieved but don’t give the team the room or responsibility to figure out how to achieve them.

Good product leaders care deeply about developing their people, both through mentoring and coaching. They can mentor because they’ve done the work. Bad product leaders are like consultants. They talk a good game but lack the practical experience and depth of knowledge. Good product leaders provide relevant, actionable advice that helps to unblock their PMs. Bad product leaders’ advice feels disconnected from the realities their PMs face.

Good product leaders give frequent and specific feedback with examples, both constructive and reinforcing. They don’t shy away from difficult conversations. Bad product leaders give unspecific, fluffy, and/or un-actionable feedback. They either focus only on the good to avoid awkward conversations or only on the bad, sapping motivation. They think of feedback only during performance assessment season.

Good product leaders praise and recognize their team's hard work and results. They give credit for successes, take ownership of failings, and ensure lessons are learned and shared. Bad product leaders take credit for successes and look for people to blame for failures. A good product leader advocates for their people, shining a light on strong performers. A bad product leader is afraid to lose their position to high-performers. Bad product leaders are in it for themselves and their careers, not their reports.

Good product leaders role model the culture they want to create. They know that every word, decision, action, or inaction builds culture, and they do so consciously. Bad product leaders complain about the culture and the people. They are unaware of how their behavior impacts culture. A good product leader fosters a culture of openness and collaboration. Bad product leaders build a culture of fear and competition.

Good product leaders proactively promote and give monetary rewards to those performing well. Bad product leaders only consider rewards when a valuable PM offers their resignation letter.

Good product leaders know when to step in and when to step out. They balance being involved and giving their team the space to work independently. They are present and supportive but avoid micromanaging. Bad product leaders are too deep in the weeds or too aloof. They either micromanage every detail or are so hands-off that they are out of touch with the team's progress and challenges.

Good product leaders are comfortable delegating decisions to people closer to the problem. Bad product leaders insert themselves into every tiny decision and meeting, not trusting anyone to make the right call. Good product leaders are on the lookout for how to unblock and support the team. Bad product leaders don’t know how to help and often hinder the team’s progress.

Good product leaders serve customers in ways that work for the business. Bad product leaders either fight the “idiots” from the business or are subservient to the business, not as partners but as waiters taking orders.

Good product leaders protect the team from organizational bullshit. They shield their team from unnecessary bureaucracy and political distractions. Bad product leaders are like a shit fan. They make unrealistic delivery commitments without talking to the team first.

In the unlikely event you are paying attention, this post is about a week late. I debated whether I should do it, but I also didn’t have a better topic. Would you help me? Send me a message with what product leadership topics you would like to hear more about:

Subscribe now

Mistake #1: Disguising outputs as outcomes

One common mistake is setting outcomes that are just outputs in disguise. For example, saying the outcome is to “deliver an Android app” is simply a yes or no question of whether the app was delivered. This is taking an output and pretending it is an outcome.

To avoid this mistake, focus on setting outcomes based on customer behavior. These could include things like “increasing the percentage of users who add items to their shopping cart” or “reducing the number of users who abandon their cart at checkout.” These outcomes are tied to specific actions that customers take and provide more information on the product's impact.

Mistake #2: Not connecting product outcomes to business value

Another mistake is setting outcomes unrelated to the company’s strategy or business model. This makes it difficult for teams to understand and communicate their impact. As a leader, it’s your responsibility to provide strategic context and ensure that your teams understand the company’s strategy and business model.

Connect your outcomes to the company’s overall goals to avoid this mistake. For example, at one company, I was working on an outcome to reduce customer support tickets for a given feature, which was a proxy for improving customer retention, our business outcome.

Mistake #3: Delegating outcomes outside of the team's control

It’s also common for teams to be given outcomes outside their control span. This might happen when executives set business outcomes and expect product teams to deliver them. Examples of this might include “grow revenue” or “increase market share.” However, these outcomes are often too broad for a product team to impact directly.

To avoid this mistake, make sure to set product outcomes that are within a team’s span of control. This could include “increase the number of users who sign up for a free trial” or “increase the % of users who adopt a given feature in their first 7 days.” These outcomes are tied to specific actions within the product and are more feasible for a team to influence.

Mistake #4: Hyper-focusing on a traction metric

At the other end of the spectrum, some teams might set too narrow of a metric as the outcome. An example of this might be “increase the percentage of users who view the performance report.” While this might be within the team’s influence, it doesn’t give them enough latitude to explore or connect the opportunity space to the company’s business outcomes.

To avoid this mistake, test your traction metric to ensure it is relevant to customer needs. Ask yourself if it is possible to have a happy customer who never uses the feature. If the answer is yes, then the metric might not be a good outcome to focus on. Instead, consider setting outcomes that are tied to the value experienced by customers.

Mistake #5: Creating too many dependencies across teams

Teams can be challenged when their outcomes require coordination with other teams, particularly if those other teams have different outcomes or priorities.

To avoid this mistake, it’s important to set outcomes that a team can influence without much help from outside the team. But there are instances when a multi-team outcome is necessary. What then? Ensure that all teams required to achieve the outcome have the same desired outcome. Nothing is more frustrating than needing another team, but the team is not very helpful because they have different goals.

Mistake #6: Measuring actions instead of the value of those actions

Often, teams focus on measuring actions rather than their value to the customer. This can lead to a product that is not as effective or valuable as it could be. For example, at a real estate marketplace where I worked, we inferred the success of people looking for an apartment by measuring whether they applied to one or more apartments. But, clearly, the value we offered was not in the application but in getting the perfect flat. We were pushing for an increase in the number of applications per seeker, but the real-estate owners were annoyed by the flood of incoming low-quality leads. At the same time, seekers were frustrated because they didn't get a reply from the flooded owners.

To avoid this mistake, consider focusing on outcomes that measure the value to the customer, even if those outcomes are not immediately measurable. As you learn more about how to impact the outcome, you can work on finding ways to measure it. Vinted, the used clothes marketplace, does this quite well: once the seller marks the item as sold, they have to select if they sold it through Vinted and, finally, pick from a list of people who messaged them who they have sold it to.

Mistake #7: Setting sentiment outcomes without any further direction

Focusing solely on sentiment metrics like customer satisfaction or NPS can be challenging for teams, as it is difficult to please everyone all the time, and these metrics are not directional.

To avoid this mistake, if a satisfaction metric is absolutely necessary, I prefer to narrow it down. For example, “increase new users satisfaction in their first 7 days” or “increase satisfaction with feature X”. But, even those could be translated into value metrics, instead of sentiment metrics. For example, “increase the number of new users who create a playlist and add 10 songs to it in their first 7 days” or “increase avg. song play time.” This is better because sentiment metrics are somewhat lagging, too.

Mistake #8: Setting outcomes without considering accountability

When setting team outcomes, it’s important to consider the accountability model that will be used to track progress toward those outcomes. If you give teams outcomes but then measure their success on their output, they will forget the outcome and just go back into feature-factory mode. That’s obvious, but one less obvious thing is that only focusing on outcome goal achievement (performance) won't work either.

If failure is not an option, you can bet goals will be set conservatively (sandbagging), as will the opportunities and solutions explored. Oddly, by focusing on performance (e.g., goal achievement), teams tend to deliver fewer results than if they focus on progress towards the outcome.

To avoid this mistake, consider using accountability models that encourage a learning mindset and focus on progress and reflection. How did we make progress towards the outcome? What did we learn? What are we going to do differently next time? If the team is moving in the right direction and learning more about how to get to the goal, that will ultimately bring the results they need.

Subscribe now

Please subscribe and smash the “like” button if you found this article useful. If you know anyone who could benefit from it, share it with them or on your social media. This is a big help!

Some would tune out. Some would go back to the comfort of the feature factory. Some would implement processes but really didn't adopt the culture necessary for them to work. Even when some transformation and improvement happened, the heavy lifting of not being able to understand (and explain) the pieces of the puzzle burnt people out.

Subscribe now

Thankfully, 3rd time's a charm. Cagan's latest book, "Transformed," cuts through the fog. It offers a clear framework for building a world-class product development organization for tech-powered companies. It frames the transformation problem in 3 big categories: 1. how we build, 2. how we solve problems, and 3. how we choose which problems to solve.

The three categories and the book's content are much easier to digest than in Inspired. But I still found it was missing a key piece of implementation: a simple checklist. So, based on Transformed's content, I made a simple checklist for product leaders to assess their product operating model:

And if you can't be bothered to open the spreadsheet, below is the list of items. Evaluate each of them with red/yellow/green:

1. how we build

1. Product teams release frequently (at least every other week, ideally multiple times a day in Continuous Delivery), and in small, reliable and decoupled increments. The opposite of this is big bang monthly/quarterly/yearly releases.

2. Product teams have a long life (don't constantly change in scope and/or members), so they develop deep tech, customer, and industry domain knowledge. The opposite of this is project-based staffing.

3. Engineering is not outsourced because it is a key product company capability.

4. Instrumenting the technology so we know it is working and how it's being used.

5. Monitoring the technology so we can detect problems before customers do.

6. Being able to prove the new capabilities deliver the necessary value before deploying widely.

2. how we solve problems

1. Every product team is assigned one or more business and/or customer problems to solve and outcomes to achieve, which they are accountable to.

2. The product team is empowered to discover a solution that is:
   1. valuable (the customer will decide to buy or use it),
   2. usable (the user will be able to figure out how to use it),
   3. feasible (your engineers know how to solve with the time, skills, and technology on the team), and
   4. viable (the solution will work for your business in terms of constraints in marketing, sales, finance, service, legal, and compliance).

3. PM, UX, TL, Engineers, and Data Analyst collaborate to identify the right solution, this is what is meant by an "empowered product team". The opposite of this is engineers just focused on building, designers just on design...

4. Product teams have unhindered and direct access to customers.

5. Product teams have unhindered and direct access to data.

6. Product teams have unhindered and direct access to business stakeholders.

7. The product team is not subservient to company stakeholders, but collaborative with them.

8. When a product team ships a feature but does not see the necessary impact, then they iterate on that feature or on their approach until they do or sunset the feature.

9. Every solution being worked on by a product team has a clear measure of success.

10. Product teams rapidly and cheaply test assumptions and product ideas to discover a solution worth building. What is "rapid" and "cheap"? The best product teams do 10 to 30 tests weekly. These tests must be at least one order of magnitude faster/cheaper than just building what they are testing.

11. Product managers are experts on how customers choose and use our products—both qualitatively and quantitatively—and also understand the market, the competitive landscape, relevant technology, and industry trends.

12. Product managers are experts in our business, which means they know how the product is funded, monetized, manufactured, marketed, sold, delivered, and serviced, as well as any legal, contractual, or compliance constraints.

3. how we choose which problems to solve

1. The company has a compelling customer-focused product vision.

2. There is an insight-based product strategy to identify the most critical problems that need to be solved to deliver on the business objectives. This means saying "no" to many things.

3. The team topology (org structure) is tailored to tackle the problems surfaced in the product strategy, while minimizing drag and dependencies between product teams.

4. C-level is bought in the insight-based product strategy and acts to increase focus by saying "no" to what is outside of the strategy.

5. Product team members are bought in the insight-based product strategy and acts to increase focus by saying "no" to what is outside of the strategy.

How is your company's product operating model?

Building a high-performing product development organization isn't easy, but with the product operating model checklist, you can transform your team from inspired to unstoppable.

If you found this article useful, please smash the “like” button. If you know anyone who could benefit from it, share it with them or on your social media of choice. This is a big help!

A product leader should be measured by their weakest PM.
— Not sure who said this, maybe it was Cagan?

A strong PM team can translate vision into reality, navigate the choppy waters of uncertainty, and launch products that users love and deliver on business goals. But how do you, as a product leader, cultivate greatness in your PMs?

Fortunately, it's not rocket science. Just focus on the basics:

Basics #1: Get the feedback loop right

Building a high-quality feedback loop—frequent, balanced, and clear—is the most important tool for helping your PMs grow.

Feedback frequency

It's common sense for product teams to optimize for the speed and frequency of feedback. This way, they iterate more and get to successful products faster. Funnily enough, product leaders don't realize that it's the same with people: the faster the feedback loop, the faster that person can iterate through their behavior, which results in more developed skills and, thus, better products.

Unfortunately, most leaders are already messing up here by not offering enough feedback frequently. It's not uncommon for (bad) managers to only think about feedback during the performance assessment cycles, which most commonly happen yearly or bi-yearly. This is not nearly enough.

It's understandable, though: you have plenty on your plate as a product leader. That's why I think about each direct report and the feedback I would give to them in my weekly Watchtower Reflection exercise. I usually don't have feedback for every direct report every week, but by making a habit of thinking about it weekly, I make sure I always have some feedback for some of them.

Feedback balance

Some leaders are uncomfortable giving praise, and some avoid talking about what they want you to change or improve. To build a high-quality feedback loop, you can't do either. Feedback must be balanced between positive things (to reinforce behavior) and negative things (to change behavior).

ATTENTION: I AM NOT TALKING ABOUT THE FEEDBACK SHIT SANDWICH.

I am not saying that you must bring positive and constructive feedback every time you give feedback. What I am saying is not to forget or avoid either one. Not to focus on only one side of the feedback.

You will only shoot yourself in the foot if you avoid constructive feedback. The bad behavior does not go away if the person is unaware — just like they won't remove a lettuce piece from their teeth if no one tells them it's there. If the bad behavior goes on for long enough, you might even have to fire this person, which will feel extremely unfair to do if you didn't clearly say that the behavior was bad.

In the opposite corner is the leader who ignores giving out positive feedback and praise. “They certainly know they did a good job” might be the logic behind this. I speak from experience to say that this is not true. Often, PMs are unaware of when they did a good job. Early in my career, I had a leader who gave me much praise in our 1:1s, and I was completely surprised because 1) I thought I was doing the obvious/basics, 2) I was super critical and demanding with myself, and 3) I had a huge impostor's syndrome.

Feedback clarity

The third and final high-quality feedback loop characteristic is that it is crystal clear.

Especially for constructive feedback, I like to write it down beforehand to clarify what I want to say. Spoken or written clarity starts with mental clarity. I use a small framework to structure the feedback content beforehand:

• Behavior: what actually was observed, the facts, without judgment. E.g.:

  “I saw that your analysis of problem X document didn't have the main conclusions at the top or anywhere in the document.”

• Impact: what the result of the behavior was. E.g.:

  “This meant that after I finished reading the document, I did not understand the conclusions, learnings, and next steps.”

• Request: what you hope the person will do. E.g.:

  “I would like you to start any such document with a top section of ‘conclusions’ or ‘TL;DR’.”

When delivering feedback, I use the Captain leadership style because I want to be clear. Then, I use the Coach style to understand the person's reaction to the feedback and work out how we can move forward from there.

PS: notice that bad/unclear feedback is often given in the Diplomat style.

PS2: One good mindset when giving feedback is to “assume good reasons, instead of just reasons” for the displayed behavior. People rarely do things with malicious intent.

Basics #2: Performance assessment as a development roadmap, not a report card

Performance assessments shouldn't be an annual anxiety-inducing exercise. If you are doing the basics #1 and giving frequent high-quality feedback, nothing appearing in the performance assessment should be new to the PM.

If something is new, you have failed as their leader.

It doesn't mean you don't need to repeat it on the performance assessment just because you said it before.

As with the feedback, I like to write down my performance assessment. I also like to deliver the written assessment before the performance talk so the person can process the feedback before the meeting.

But the most interesting part of the performance assessment is arguably not the part where you look back at what happened but the forward-looking bit. The most important part of the performance conversation is the leader and the direct report coming to a shared understanding of the good and the bad and what is expected to be improved and delivered on the next performance cycle. Building a development plan with the direct report is the roadmap for that PM's growth.

Very helpful: a PM competence framework with levels

People expect a lot from PMs. So much so that what is expected (mandatory) and what is nice to have can be confusing. In my experience, performance conversations can get really hard for the direct report to grasp without a good competence framework that outlines the behaviors expected from each PM level (APM, PM1, Senior PM, etc). This is because the competencies required are so broad (e.g., “get better at strategy”) that it is hard to understand what behaviors need to be developed, not to mention how.

If your company doesn't have one, you can begin creating or adopting one with your direct reports. I really like Intercom's PM competencies.

Basics #3: development plan follow-up and support

An unused plan in the drawer (or Google Drive) is as good as no plan. The product leader must follow up on the development plan and support the direct report in achieving it. This is also in the leader's interest: better PMs deliver better results.

For the development plan follow-up, there are 2 basic tools:

• 1:1 meetings; and

• Mid-cycle reviews.

I already spoke plenty about 1:1 meetings that don't suck, so I will concentrate on the mid-cycle reviews:

I like to run informal performance reviews in the middle of the formal performance cycle. This is another tool to avoid surprising the PM during the formal performance cycle. It is also a milestone for the direct report to understand what is on track and what needs correcting. I use the exact same format as the formal performance review.

But remember, it's not only about following up with your direct reports. You also have to support them. This can mean several things, like working on something together, giving more frequent feedback about a certain development area, giving stretch assignments… you have to keep an eye on opportunities to support their growth.

Go and get those PMs to the next level

Remember, developing PMs is an ongoing process, not a one-time event. By implementing these simple basics, you'll cultivate a team of confident, skilled PMs who are not just building products but remarkable careers—and that's a legacy worth leaving.

If you found this article useful, please smash the “like” button. If you know anyone who could benefit from it, share it with them or on your social media of choice. This is a big help!

Why prioritization frameworks fall flat

There's a seductive allure to a framework's clean lines and neat boxes. You can't argue against numbers. But the reality is that product decisions rarely exist in a pristine spreadsheet world.

Here's how frameworks can lead us astray:

1. The cult of the quick win

Prioritization frameworks often incentivize focusing on low-hanging fruit, neglecting bigger, unknown, strategic bets or with longer-term payoffs. This is ok for mature products that only optimize to extract more value, but this will never lead to the next wave of growth.

If you continue with the quick win approach, you will be blindsided by a competitor who will make your quick wins irrelevant because they delivered big value that you could not see (or, worse, saw but never prioritized).

2. Gaming the system

Let's be honest: people are resourceful. A number-focused framework can be easily manipulated to favor pet projects or suffer from confirmation bias. Suddenly, that "nice-to-have" feature magically inflates its "reach" score.

3. Blind faith in numbers

Frameworks can lull PMs into a false sense of security, trusting the numbers over their own intuition. But product management isn't pure math. There's an art to it, a feel for the market and your users that spreadsheets can't capture. This feel, often called “product sense”, is built on years of domain knowledge, previous experience, etc.

I understand it's comfortable: “I didn't make this call; the numbers did.” But to be a great product person, one must commit to decisions, even (especially?) ambiguous ones.

4. Executives not falling for it

Ever spend hours crafting a beautiful prioritization chart, only to have a C-Level executive shrug it off and mandate to build a certain pet feature? That's because the quackery of spreadsheet prioritization was deemed as BS — and since you don't have a better argument than “this feature has a 10.3 RICE score while this other is just 10.1”, you lost their confidence, and they go with whatever they think is best. Certainly very annoying, but you had it coming.

Building on a better foundation

So, what should product managers and leaders do? Throw out the frameworks entirely? Not quite. They are helpful as a thinking methodology, but ultimately, the decision has subjective aspects. But we must address the root cause of the blind faith in numbers. It often boils down to two things:

1. Either PMs are misjudging their role, thinking that what they do is pure science and not with equal parts art/feeling/product sense or whatever you call it;

2. Or they adopt prioritization by numbers because they want some semblance of control. Often because their leaders are mandating conflicting solutions. They want to “prove” feature X is more important than Y, so they don't let the CEO down by saying “no” to their pet project. It can also be that the “lack of control” felt by PMs is impostor syndrome — they don't want to commit to something because they are afraid of being wrong.

The solution to problem 1 is to align with that PM, but for number 2, I find a few things can help:

1. The 70/20/10 rule of thumb

Fear of big, hairy, unknown problems/opportunities is normal. But any organization that avoids this eventually is toppled by competitors thinking broader/differently. On the other hand, organizations that only work on left-field initiatives might lose their current business because they only work on future stuff and forget the present.

At an organizational level, leaders should use the 70/20/10 rule of thumb for resource allocation: 70% goes to your core business, 20% to adjacent innovations, and 10% to wild ideas. This ensures stability while nurturing future growth and also guides PMs about what the business expects of them.

2. Allocate goals, not features

It should be clear what business goals a team must contribute to and how much this contribution should be. Product leaders need to allocate clear goals to their product managers and let them loose on how to achieve them. I am not saying to go to macromanagement, arguably as bad as micromanagement. However, product leaders must trust their people to make the best decisions on the ground. You can debate and be their roadmap editor, but it's essential to give PMs the space to deliver results (and be judged by them).

3. Share goals to resolve conflicts of prioritization

Spreadsheets are often used as weapons in the corporate war by product teams with dependencies on other teams to achieve their goals:

PM1: — Look at this amazing RICE score, my feature will deliver on the strategic goal X, your team has to help mine!
PM2: — Well, the thing is that my team is working on goal Y. — Unsaid, but thought: — And my promotion depends on me achieving it.

The root cause is that they should work together but don't have common goals (likely the product leader's fault). As a product leader, you must be cognizant of that and allocate the same goal to teams that must work together to achieve something.

4. Incentivise PMs to talk about the impact of deliveries

There is nothing wrong with executing and delivering on features. It's essential to what we do. But there must be a tight feedback loop between “we did this” and “so we achieved that.”

In feature factory type of companies (fertile ground for spreadsheet prioritization), this feedback loop will start to educate PMs and stakeholders pushing for features about the impact of their decision. Most people, when faced with the reality that their brilliant idea didn't move the needle, will start to look for other ways to prioritize.

(OK, some will push harder and blame the team for “not doing it right”. It might not be a place to stay, though).

5. Have a clear strategy (and evangelize it)

If either the company or product strategies are unclear, it is harder for PMs to prioritize. If they have no logical way to prioritize between competing features (or even goals), they are likely to look for a spreadsheet for help.

Closing thought

Prioritization frameworks (like any framework) are tools, not gospels. They should be used as input to the decision but not as the decision maker. They can't replace product judgment. Spreadsheets are not accountable to goals; people are.

Did you enjoy this article? Click the like button and share the article with your network, this is a big help to me.

What are the Captain, Coach, and Diplomat styles?

Think of it as different ways to act as a leader. We shouldn't be 100% one or the other. We have to adapt to the situation. The Captain and the Coach are useful at different moments, while the Diplomat must be avoided at all costs.

The Captain is direct, clear, and task-oriented.

The Coach hands over responsibility and helps the person reflect and grow.

The Diplomat tries to maintain the status quo and avoid conflict. Considering leadership can be summarized as “goal-oriented influence,” this is terrible leadership behavior and should be avoided.

But even if the Captain and Coach are useful styles, they must be used in the correct situation. If not, they do almost as much damage as the Diplomat.

Example: the Titanic is heading toward an iceberg

The Captain:

Captain: This is the captain for the engine room.
Engine room: This is the engine room, captain.
Captain: I need you to change course to XYZ immediately. We are heading into an iceberg. Confirm.
Engine room: Aye, aye, captain, changing course to XYZ immediately.
Captain: Thank you. Over and out.

The communication is unambiguous, but the Captain confirms it was understood anyway. It's direct and task-oriented, with no room for interpretation. Clarity is key.

It's on the nose that the effective style for a boat in an emergency situation would be the Captain, but it illustrates the point well.

The Coach:

Captain: Hi, engine room. How are you feeling today?
Engine room: Very good captain. And you, sir?
Captain: Amazing, thanks for asking. What do you think of our current speed and heading?
Engine room: They seem fine, sir. All motors are full-speed ahead.
Captain: Fine indeed! But what do you think of the iceberg problem?
Engine room: Sir?
Captain: Oh, yes, you don't know. You see, there is an issue. We are heading straight into an iceberg.
Engine room: Oh my god, sir! What are your orders?
Captain: What do you think we should do about it?
Engine room: Change course, sir!
Captain: Perfect, good idea! That's what I wanted to hear. Thank you, engine room. You are doing fine work down there.

That sounds like it could be a Monty Python sketch because it's using the wrong leadership style for the situation. Coaching is super useful, but it can also be overdone. More than once in my career, I screamed in my head, “Just tell me, I don't know!”

The Diplomat:

Captain: Hi, engine room. How are you feeling today?
Engine room: Very good captain. And you, sir?
Captain: Amazing, thanks for asking.
Engine room: Do you need something, sir?
Captain: I don't want to bother you, but since you asked, maybe we should change the course a little—if that is okay with you.
Engine room: Why, sir? To what heading?
Captain: Nothing major, don't worry about it. Just keep around X and Y.
Engine room: Which one, sir? X or Y?
Captain: Well, whatever doesn't rock the boat too much. I trust you to make the best decision.

The Diplomat doesn't even talk about the problem. He doesn't want to rock the boat, figuratively speaking. The Diplomat is unclear and disempowering. It's the wishy-washy of the in-between.

When to use the Captain and the Coach

Evangelizing vision, strategy, and goals

This is a clear job for the Captain. You want to be clear and convincing. You are selling, not building consensus.

On the other hand, when building a vision, strategy, or goals, depending on how bottom-up the culture is, it's common to engage the Coach. The mistake is to keep being the Coach (or worse, the Diplomat) and look for 100% consensus, which leads to compromise. At some point, the leader has to draw a line in the sand and say, “We got your input. This is my decision. Let's go!”

Giving feedback

Feedback has to be crystal clear to be understood. This is also a job for the Captain. The situation, facts, impact, and desired state must be clear. Leaders oftentimes tip-toe around this and end up with a problem that only grows. Especially with hard feedback, I like to write it down first: verbal clarity comes from mental clarity first.

After the feedback is given, it's time to engage the Coach. The Coach should actively listen to the person's reaction to the feedback, ask clarifying questions, and help the person build a plan for the next steps.

PS: Yes, feedback also means “performance assessment.”

Adapting to the report's task maturity level

Task maturity is a person's competence level in performing a task. The lower the maturity, the more the Captain should be engaged. When the task maturity is higher, the Coach should be engaged. This avoids being too prescriptive and micromanage-y to reports that can already work independently while also avoiding being too loose and macromanage-y for the ones that need more hand-holding.

Career talks

These tend to happen in 1:1 meetings. It makes sense to engage the Coach to make the person reflect and create a plan to further their career.

Emergencies and incidents

100% the Captain. After the emergency is averted, the Captain might still give feedback about the performance. Then, it might be good to engage the Coach to understand what happened and what we could do to avoid such a situation.

👋 Hey, this is Sergio with a new edition of Product Leadership IO. In every issue, I write about challenges product leaders face in the real world, the 99% not working at FAANG companies or Big Tech. I publish every two weeks, and you can subscribe for free here.

I once had a leader whose 1:1 meetings were so bad that I celebrated when he would cancel them. He loved the sound of his voice. He was always proactively offering “deep” life lessons, often related to anecdotes of one of his volunteering trips to developing countries. I later discovered that the anecdotes were not even tailored to me — all PMs would get the same “inspiring” stories in their 1:1s. I always thought “damn, I could be doing some real work, instead I am listening to a story about a street musician called Manolo”. I would leave the meeting more confused than when I came in and just went back to do my work.

I eventually quit that job, letting go of a bunch of unvested shares, largely because of this leader (not only his 1:1s). While that is an extreme case, I have had my fair share of bad 1:1s. I’ve also been blessed with many outstanding leaders who really knew how to run those meetings. As a cherry on top, I've worked with talent development in my career before product. Because of all this, I feel I can teach a thing or two to take your 1:1s to the next level.

As a leader, what is the benefit of 1:1 meetings?

One of product leaders' most important jobs is supporting the growth of their PM reports. This is not out of the goodness of their hearts. PMs that are growing and improving will deliver more business results.

Also, according to Daniel Pink, there are three drivers of intrinsic motivation: autonomy, mastery, and purpose. Motivated people are more likely to go the extra mile, again delivering better business results. And guess what? The one-on-one meeting is a great vehicle for working on all three:

1. Mastery. The product leader supports the development of their reports by helping the Product Manager grow through a balance of teaching (mentoring), asking the right questions (coaching), and giving clear feedback.

2. Autonomy. The product leader can use coaching (asking questions) to help their direct reports reach their own conclusions and answers. Also, PMs gain more autonomy as they develop mastery in their craft.

3. Purpose. Last but not least, 1:1s are a great medium for conveying the importance of what the PM is working on in relation to the company's and product's priorities.

But how do you deliver a good one-on-one meeting as a leader?

The direct report owns the agenda

One-on-one meetings are for the benefit of the direct report. They own the agenda, not their leader.

I always make this clear to my direct reports: the 1:1 will be as useful to them as the quality of the topics they bring to it. I nudge them to prepare the topics in advance. They should not treat as a random conversation with their leader, but a leverage for them and their work.

Prepare for the meeting

Just because the product manager is bringing in topics to discuss doesn't mean the product leader shouldn't do the same. The difference is that the priority is to go through the report's topics first, going to the leader's topics only if there is enough time. What if there isn't? Then, the leader schedules an ad-roc meeting to address those points, or they wait for the next 1:1.

I prepare for next week's 1:1 on my weekly Watchtower Reflection exercise by thinking about my goals for the next week and how I can achieve them, which often involves talking to my PMs.

One anti-pattern to watch is when the direct report asks to prioritize the leader's topics first. Don't let this happen. They are either trying to please you (at their own expense), or they didn't prepare enough for the meeting, which is a bad sign.

Frequency and length

Different people have different needs.

That said, I gravitate between weekly for most PMs and fortnightly for more senior ones who want less hand-holding (and are able to).

I also strongly prefer 1 hour or at least 45 minutes in length. I think 30 minutes or less is too rushed, without any space for personal chit-chat to connect with the person. If all the topics are done before the end of the meeting, you can always end early or double down on the chit-chat.

Treat 1:1s as a priority

Some leaders often cancel 1:1s, which signals that developing their people is not their biggest priority. Big no-no.

Unless all hell breaks loose, I go to great lengths not to cancel 1:1s — once, I drove for 30 minutes to find a cellphone signal after a typhoon had destroyed the city's electrical and communications grid:

But if you really have to cancel it, you should propose a new timing on the cancellation itself. Make sure not to miss this one.

Don't talk more than your follower

Don't be the leader who loves the sound of their voice. If you are speaking too much, you are not giving your product managers space to ask questions and address their biggest issues. You might also be overindexing on teaching (mentoring) instead of supporting the PM to find their own answer (coaching).

Create rapport, especially in new relationships

While AI might replace us all, we still must connect as human beings to work better together. No product manager will be transparent about issues if they don't trust you as a person. Connect to their lives, ask and share about the weekend, vacation plans, random pet peeves, etc.

1:1s are not status report meetings - don't neglect the PM's career and life

Another anti-pattern is talking only about current work, not future aspirations and expectations. You have to discuss what the person wants for their career: What is their ideal next role? Do they dream of doing something? Are they being able to get the most out of life?

If, like me, you are not an outstanding conversationist, you can use something like the Magic Questions framework:

Ask one or more of these questions and ask your direct report to score it from 1 to 5.

1. Is what you are doing now at work leading you toward your career vision, 1-5?

2. How are you feeling about your life at work, 1-5?

3. How are you feeling about your personal life, 1-5?

4. How are you feeling about your physical work setup, whether at home or the office, 1-5?

5. How are we performing as a company, 1-5?

6. What is it like to work with the rest of the team (your peers), 1-5?

7. What is it like to work with me, 1-5?

The scale is:

1 - It couldn’t be any worse
3 - Meeting expectations
5 - It couldn’t be any better

Then ask “what would get it to the next scoring level?” to discuss improvement plans.

Document decisions and follow-up

In your 1:1s, you should agree on to-dos and decisions, which should be documented—ideally by the direct report.

Follow up in the next 1:1s and in between meetings whenever appropriate. If your report finds out that you forgot those tasks, they will be less likely to execute them.

Obviously, if you are assigned a to-do, don't let the PM down by not doing it. Walk the talk.

I tend to favor simplicity when tracking this. For example, I share a 1:1 Notion page with my direct report, including meeting notes by date and a category for open to-dos.

As a product manager, I've lost count of the years that I have spent trying to understand how to even represent a product strategy, let alone craft one.

It always felt like product strategy was something amazing product leaders did, but I couldn't replicate it. This was even tougher because most examples out there were so far away from my reality - I am looking at you talking about Netflix strategy.

⚠️ Before you start ⚠️

Before any product strategy crafting attempts, the company vision and strategy need to be clear. 90% of the problems I had in crafting the product strategy stemmed from not having this in place. You can't build a house on top of an unstable foundation. Or, you may, but it will collapse. You will never be able to craft a good product strategy without a good company strategy.

If your company's strategy is missing or not up to snuff, read the article “Your company strategy is sh*t” first. I’ll wait here.

Company strategy in place? OK, let's go.

Products strategy or a strategy for a given product?

I want to clarify up-front: this article is to help you build a product strategy for a specific product (or even a large enough feature inside a product). This is usually what PMs and product middle managers (group PM, product lead, head of product, director of product…) have responsibility for.

This article is not about creating the products portfolio strategy of the company - which is something a CPO would have responsibility for.

Product strategy is surprisingly similar to any other product management work

Product management is nuanced but straightforward, it can be boiled down to a few high-level steps:

1. Desired state: you want to achieve some outcome and/or solve a problem.

2. Current state analysis: what is the status of this outcome/problem? How do you measure progress?

3. Opportunity investigation: then you decompose this complex thing into more manageable bits: you investigate the key levers and/or issues most relevant to the goal/problem. These are your opportunities.

4. Choose opportunity: you pick the most promising opportunity to tackle.

5. Solution hypotheses: you come up with solution hypotheses, validate them, and finally implement the ones most likely to work.

6. Track progress and course-correct: as you implement the solutions, you measure if they are delivering the goal impact you had in mind. Based on lessons learned, iterate as needed.

7. Rinse and repeat.

With product strategy, it's very similar:

1. Desired state - high-level product strategy: how your product contributes to the company's vision and strategy execution.

2. Current state analysis: the status of the desired state. Where are we?

3. Opportunities investigation: possible levers/issues to bridge the gap between the current and desired state.

4. Choose opportunities - strategic initiatives: the opportunities you choose to act upon, and how you will measure progress towards them.

5. Solution hypotheses - big rocks: list of the 2-3 main broad solution hypotheses to achieve the strategic initiative.

6. Track progress and course correct: as you execute on the big rocks, you measure if they are delivering the goal impact you had in mind. Based on lessons learned, iterate as needed.

Let's dive one by one:

Subscribe now

1. Desired state - high-level product strategy

This is the first rock I used to trip before I understood the importance of having a clear company strategy. You need to understand the company's vision and strategy to know how your product fits within it. 90% of product managers and leaders’ confusion stems from arguing about product strategy in a vacuum. It's just too hard.

I will try to illustrate with an example of a fictional German neo-bank operating in Germany called Neo Bank (creative, I know). Imagine you are the PM responsible for introducing a new “buy now, pay later” (BNPL) product. If Neo Bank was the typical company with a bad strategy, you would be given the goal of “reaching 10m BNPL transactions” or something like that and that was it. Do you feel empowered already? 😅

But Neo Bank is not the typical company, so there is a clear company strategy to build on top of:

The product leader responsible for BNPL, together with engineering, UX leads, and any other relevant stakeholders, come up with the following product strategy:

We can see how easy the strategic choices of the Buy Now, Pay Later product feel because the company strategic choices are clear. A few examples to highlight:

1. Winning aspiration: Most of it will come from the company leadership. If not, why would they be investing in this product if they didn't want something from it? You can add a more visionary spin to it too.

2. Where to play: the target market is derived from the company strategy.

3. How to win: they didn't need to be the cheapest offer in the market, because the company strategy outlined that they would acquire customers with a free basic bank account, but have “reasonably priced” (not cheapest, not most expensive either) additional products. This is a money maker product, higher margin.

   
   It's also interesting that the team is not trying to convince merchants to adopt a new payment solution. Neo Bank unfortunately doesn't have a lot of relationship with merchants, because it's a consumer-focused mobile bank. So their decision was not enabling BNPL to merchants, but enabling users to opt-in to BNPL in their transactions.

   
   Finally, their machine learning models should be able to predict the risk of the loan and offer an automated decision. This is way easier to Neo Bank because they already have all the user’s transaction data.

4. Capabilities: there is a high overlap between what the company needs to be good at and what this specific product needs. This is good. It's not unheard of that specific products would have different capability needs than the org. But if there is almost no overlap between company and product, it might be a red flag.

A few pointers:

1. This high-level strategy is an assumption until it is validated. I don't want to repeat myself, so you can just check about strategic assumptions surfacing and validation here.

2. Once this is done and validated, there is not a lot of change in 2-5 years. More ambitious product strategies might go for an even longer timeframe.

3. Maybe you are a PM with a feature or use case inside a product with a high-level strategy - if so, you might build on top of it, instead of creating a whole new set of strategic choices.

4. Also, if the company has just one product, the company strategy is (likely) the same as the product strategy.

2. Current state analysis

Look at your validated product strategy from the step before. Assess which parts are not there yet. What are the main issues you are facing?

One cool idea for doing this came from 's podcast episode with : make a list of the 10 main problems with the product. This is a living document, so as the problems get solved, the 10 top issues also change.

In the BNPL example above, one part of the “how to win” is that this is the “easiest BNPL to use”. Let's say that it is not true, we have plenty of support tickets from people who can't figure it out. So that is a gap between the current state and the desired state.

3. Opportunities investigation

Investigate and decompose the problems you listed in the previous step. Following the example, why are users raising too many support tickets about BNPL? Maybe they can't figure out which transactions are eligible. Or maybe they don't understand how much they are paying. Or they don't know how to turn a transaction into buy now, pay later? You get the gist of it.

4. Choose opportunities - strategic initiatives

Pick your strategic initiatives based on what you believe is crucial to progress toward the desired state.

Remember you can't do it all at the same time, so sometimes you have to let some fires burn to fix what is most important. It might be useful to stack-rank the opportunities.

It's important to also pick metrics and set goals for your initiatives. How do you know you are progressing in the right direction?

5. Solution hypotheses - big rocks

You have investigated these problems. You probably have a feel for the most important product changes to address. Don't shy away. Even if your big rocks are wrong (PMs should validate these things) it gives a pretty good idea of where the impact of the strategic initiative is coming from. Also, it gives you an idea if you are understaffed by trying to do too much with too little.

Ah, this should be 2-4 things. The small stuff, like changing a button's label, is certainly helpful, but doesn’t need to be listed here. Leave this for the team's roadmap.

6. Track progress and course-correct

As you execute your plan, you should track your progress toward the goals you defined in the 4th step. Do you need to change the strategy? Or the big rock? Don't wait for the next planning cycle. Do it sooner rather than later.

By now you have a product strategy and a way to deploy it

Congrats are in order 🎉

Let me know how you did, if you stumbled somewhere, or if it was confusing at some point.

If this was useful to you, smash that like button and share this so others can benefit too.

Product people always complain they can't do their jobs because the strategy is unclear. And they are right. However, when you ask them what they mean by “strategy”, no one can tell. The sad reality of my 12-year career building products is that most companies have no coherent company strategy - which means their product strategy is also not.

The strategy is not only bad.

It's non-existent.

But it's not for the lack of trying. Every company has some form of “strategic planning”, vision, goals, list of priorities, yadda yadda yadda. They are most often not a strategy though.

Subscribe now

What is “strategy”?

There is much confusion about what it is, which means that often what is called "strategy" or "strategic planning" is anything but.

Strategy is a young discipline, so there is no single accepted definition of strategy. But let's pick 3 influential authors (highlights are my own):

"Strategy is an integrated set of choices that uniquely positions the firm in its industry so as to create sustainable advantage and superior value relative to the competition." - Lafley, A. G.; Martin, Roger L.. Playing to Win: How Strategy Really Works

"Competitive strategy is about being different. It means deliberately choosing a different set of activities to deliver a unique mix of value." - Porter, Michael; What is Strategy?

"Strategy [is] a route to continuing Power in significant markets. Power [is] the set of conditions creating the potential for persistent differential returns [over competitors]." - Helmer, Hamilton. 7 Powers: The Foundations of Business Strategy

On those definitions above, there are two common themes for “what is strategy”:

Sustained advantage over the competition

The goal of strategy is to win the game, not to participate in the game. If you are a general, you don't build a strategy to keep fighting on the battlefield, you build a strategy to win the war.

The way to win is by delivering more shareholder value by having lower costs and/or commanding higher value for similar costs than competitors. But this is not enough to win. This advantage must be hard for competitors to copy, thus being sustained (persistent) over a long period to be material.

In customers' minds, Netflix DVD had more value than Blockbuster because the former didn't charge late-return fees. This advantage was sustained because Blockbuster could not imitate Netflix. After all, it earned about half of its revenue through late fees. It would cripple its business model. Similarly, it was hard for Blockbuster to work in a DVD-by-mail format, because it had all these stores in every corner. What to do with them?

Deliberate choices to deliver unique/superior value

The company needs to deliver more value for the target market than the competition. The goal is not to offer a "me too" product, but a product that wins over competitors.

Netflix's DVD-by-mail business was a subscription business where users didn't need to leave their homes to get movies, didn't pay late return fees, and could watch as much as they wanted with a single monthly subscription. This delivered superior customer value (in the consumers' minds) to the Blockbuster pay-by-rental model.

These are not a strategy:

…a vision is not a strategy

Vision is a fancy name for “what this company wants to achieve in the future”. It's important for building a strategy, but it's not a strategy. It's a wish. It tells us “what” winning means for the company/product, but it doesn't tell us how to achieve it.

Want proof? Look at these two vision statements:

Figma: make design accessible to everyone.

Canva: empowering the world to design.

These are kind of the same thing. Or, at least, very very similar. However, they have very different strategies about how they are pursuing their vision. They have different theories about how each is going to win.

…a goal is also not a strategy (yes, OKRs aren't either)

According to Richard Rumelt in the book Good Strategy/Bad Strategy, "Many bad strategies are just statements of desire rather than plans for overcoming obstacles." This is mistaking goals for strategy.

The equivalent of mistaking goals for strategy is a sports team coach saying "winning" or "scoring" is the team's strategy to win. Goals are important, but how to proceed to achieve them lies at the heart of strategy.

A typical goal, "grow revenue by X%”, doesn't tell us how. Are we entering a new market? Expand internationally? Increase our prices? Cross-sell? Create a new revenue line? “Grow revenue”, without a theory of how to do it, is just a wish.

…a roadmap is not a strategy too

The roadmap is your theory of how to execute the strategy, not the strategy itself. Using the roadmap as a proxy to the strategy leads to bloated products that serve no one.

As a product leader, how do I build a good strategy?

“How to build strategy” is a topic that often goes to two extremes: either it gets intangible/exoteric, or nitty-gritty fill-in-the-blanks on the template. Neither tends to help us mortals to create a good strategy.

First things first: a clear company strategy is a must-have for any product strategy

Companies with just one product tend to have the same or very similar company and product strategy. As things grow, it's normal to have an overall company strategy and then a strategy for each product. But one thing is certain: if you don't have a company strategy, you will struggle with the product strategy.

Just like a new product feature is just a way to deliver some business outcome, a product strategy is just a way to deliver on the company strategy. This means, that before having a product strategy, you must have a company strategy.

To visualize this, I like the concept of the Product Strategy Stack by :

Looking at the Product Strategy Stack above it gets really easy to understand why PMs complain about unclear strategy when the company strategy is unclear. Also, the reason why you can't seem to nail product strategy as a product leader. If the top layers are not clear, the bottom ones won't be either.

One neat feature of the Product Strategy Stack is that if you focus on a given item, you can ask “how?” by walking one level below and “why?” by walking to the level above.

PS: I am not super convinced that “Product Goals” should come after “Product Roadmap” as explains in the article. I tend to switch them but I am not going to argue that here, I think both can work given one is careful. Try and see.

No company strategy? DON'T start by creating one

When the company strategy is not defined or unclear, some product people tend to try to create one by themselves. This is a nice exercise, but a bit of a waste of time (unless you are a founder or have founder-level powers).

There must be some theory about how this company is going to win. And it often is in the heads of the CEO and other C-level/founders. So, get it out of their heads and write it down. But how?

You can put the relevant people in a room and conduct a workshop. I would avoid that though. Unless you are dealing with a particular type of people, this can be seen as a waste of the executive's time. Which is not conducive to a great workshop. In 15 minutes everyone is on Slack and it's over for you.

I prefer to have a consultant-style approach: have some 1:1s with the relevant people. Explain that you are trying to understand (not create) the company strategy. Then ask questions and let people talk. Which questions? Here are some examples:

1. Do we have a vision/mission written somewhere? What are they?

2. If the company would be wildly successful, what would it be that we achieved?

3. What is our main target market today? Do you see this shifting to other targets in the future?

4. What problem does this target market have that we are solving? How do we intend to solve this problem? And why would they choose us instead of the competition?

5. By the way, who are our main competitors? In what are they better/worse than us? Are there indirect competitors (like substitutes)?

6. To beat the competition, what do we need to be really good at? What doesn't matter that much for us to be good at?

You get the gist.

Writing the company strategy down

After the conversations, it's time to compile a written output of what is the strategy (according to them). Show them the output. Likely there are things wrong or that the different C-level people disagree, iterate until they are satisfied.

You can write a 2-pager doc, make a Figjam/Miro diagram, or anything you want as long as the choices are clear. I hate fill-in-the-blank templates, but one format that I find very good is the Strategic Choices Cascade from the book Playing to Win. It gives the right amount of guidance, but at the same time is not stifling. It is still very much based on deep thought and research.

The Strategic Choices Cascade tries to answer five interrelated questions:

1. What is your winning aspiration? The purpose of your enterprise, its motivating aspiration.

2. Where will you play? A playing field where you can achieve that aspiration.

3. How will you win? The way you will win on the chosen playing field.

4. What capabilities must be in place? The set and configuration of capabilities required to win in the chosen way.

5. What management systems are required? The systems and measures that enable the capabilities and support the choices.

Here is an example for Netflix:

The real work begins now: assessing the strategy

Writing it down doesn't mean it is a good strategy or even a coherent one. The real magic happens when you evaluate the assumptions that hold the strategy together. If this is not done properly, this is where you will be stuck in the mud by infinite C-level disagreement. See, a strategy can only be proven successful after it's implemented. This means people will have different opinions about what might work or not. If you engage in arguing opinions, you will lose (unless you are the CEO).

Instead of arguing opinions and having each person defend their idea, do the smart thing: discuss the assumptions that hold a strategy together.

To do so, you ask “given these strategic choices here, what we believe must be true for it to work?”

This takes people away from the mindset of defending their ideas and attacking others’ ideas, to discuss what facts must be true for it to work. It's subtle, but it works.

To give some direction to the discussion, it's useful to evaluate the assumptions thinking of 4 criteria:

1. Industry Analysis. What must we believe about the strategically distinct segments and the target attractiveness?

2. Customer/Channel value. What must we believe our end customers and channels value?

3. Relative Position. How must we believe our capabilities and costs stack up against competitors?

4. Competition Response. How do we believe must competitors react or try to counter our choices?

Again, the (non-exhaustive) Netflix example:

Your goal should be to get to an agreement about each statement. I like painting them with the traffic light system: red means the statement is false, yellow it's a maybe, and green that the assumption is true.

If you can get C-level to agree on the assumptions, then any red assumption needs to go. Which means considering different strategic choices. It's a highly creative and iterative process to get to the company strategy. If you have some green and some yellow, you need to design tests for the yellow ones.

PS: assuming the assumptions are crucial. If they are not crucial, you don't need to write them down.

You have a business strategy, now what?

If you played your cards right, you should get on the other side with a clear business strategy that was built together and agreed with the C-level.

I bet you will find it much easier to define your product strategy now. You look at the strategy, assess where are the big levers/opportunities/problems, and define some strategic priorities and sequencing. It's bread-and-butter product work.

Don't shy away from repeating the process and building a strategic choices cascade and assumption testing for each product. If you want to do it, do it. But if you understand your customers, competitors, and industry well, it will feel almost intuitive to define 3-4 big strategic product initiatives.

This is not one of my typical posts about product management, because it could be used by any type of knowledge worker. That being said, product leaders are super busy, so it did become a huge leaver in how much impact I was able to deliver.

The busy person problem with time allocation

Product leaders have multiple competing priorities coming from all sides. It's easy to spend most of the time reacting, instead of proactively investing our time in the most impactful things. When this is happening, it's common to feel your calendar is not yours anymore, and you work overtime to "get some work done".

Working longer is an unsustainable solution, that's where the Watchtower Reflection comes in.

What is the Watchtower Reflection

The Watchtower Reflection is a technique to help you get out of the day-to-day firefighting and responding mode. Its purpose is to pause and reflect on the current situation (hence, like climbing a "watchtower" to observe what is below) and drawing a plan based on that reflection.

There are weekly and daily components to it.

Weekly reflection

I book on my calendar the last 2 hours of every Friday for the Watchtower reflection. I usually take less time, but this gives you breathing room.

Highlights and lowlights of the week

I start out reflecting on highlights and lowlights of my week in a few categories I choose to be the most important ones:

The first time you do it, you need to define some categories that are important to you.

As I write this post, the big and small areas I have are:

1. Personal
   - Health
   - Family
   - Career

2. Product lead
   - Direct report A
   - Direct report B
   (…)
   - Product X

3. Stakeholders
   - Leader
   - Peers
   - C-level

Those change over time, but not too frequently. If they do change too much for you, you might be setting it at a too granular level. Which is ok if it works for you 🤷🏽

Setting goals in each category

After I've reflected on the highlights and lowlights of the week, I draw some possible goals in each category. Sometimes some categories have none in a particular week because I am choosing to focus somewhere else.

After this brainstorm of possible goals, I pick a few that I find the most important. Then, for each chosen goal, I brainstorm actions I could take to reach the goal. After that, I choose the tasks I want to commit to.

For each goal, I do something like this:

GOAL: stop annoying behavior from direct report X
Actions:
1. Write feedback with clear example of the behavior and the impact it had in me
2. Share feedback on 1:1

After this, I add those goals and actions on my to-do list for the week. If there is something I can do right now, I also do it (remember, I reserved 2 hours for this). The goal is that you set your next week for success.

Daily reflection

At the beginning of my day (and when things are too hectic, sometimes at the end), I reserve about 10 min to review those goals and actions. Also, to choose what I want to accomplish on that day.

I paint each goal in red, yellow, or green. And I think if I need some course correction, like adding/removing actions. Sometimes I also remove/change goals based on the situation, but that is not very frequent. I choose what I want to do on that day based on this smaller reflection.

Closing thoughts

That's it. It doesn't look like much because it really isn't. But the change in how much you will be able to achieve will be palpable in a very short time. There is also the added benefit of being able to celebrate at the end of the week when you reach your goals — it's very easy for us to just focus on what still needs to get done, not thinking about what was done and what was good about the week.