AI coding tools are gaining in popularity, and if you've been anywhere near social media, you may have heard the term "vibe coding" recently. This concept is gaining traction and has already expanded to "vibe marketing", and isn't something you should ignore.

As a Product Manager, you should at least be aware of what vibe coding is, and although AI coding tools can play a valuable part in the development of your product, think of it as a turbo boost for now, not a replacement for developers. Don't expect everything to change dramatically for you and your teams, at least not yet.

With vibe coding, the idea is simple:

1. Describe what you want to build - just like writing a PRD.

2. Let the AI build it - No need to know how to code, but it can help.

3. Debug - Copy and paste any errors back to the LLM, instructing it to fix them.

4. Launch and iterate - Hit publish. Need to make changes? Just tell the AI and re-publish.

Does this mean you no longer need to work with your engineering team, instead doing all of the development yourself? Not at all. Besides, you have enough to do already, and there are some limitations with vibe coding preventing this from happening:

• Large code bases can quickly become unmanageable and non-human readable, making debugging difficult.

• Many existing production systems are proprietary and aren't documented well enough for AI tools to understand, limiting their effectiveness.

• You can sometimes get bad vibes and may need to start over if you get stuck in a dead-end loop.

• AI tools, especially UI-focused ones, often re-generate entire applications to make one small change, which is inefficient and messy if committing code to version control like Git.

• Security is still a huge responsibility that AI coding tools often overlook.

The Tools

There are two categories of tools. Low or no-code tools, and code first. Here's a short list of some of those tools, but there are more than what's listed here, and new tools are always popping up.

Low-code tools:

Coding is optional here. Visual editing and updating via prompting are the ideal modes of operating. Start from nothing, and speak something into existence. These tools include:

• Lovable

• V0

• Bolt

• Replit

• Rork

• Firebase

Code first tools:

You prompt the AI to generate code for you, but you also review the code, reference specific snippets in your prompt, define your own rules and work with an existing codebase. They require a code editor to work. Popular options are:

• Cursor

• Windsurf

• Copilot

• Cline

You might be wondering why I didn't mention Claude.ai or ChatGPT. Although they can write some code for you and even generate a preview, they are limited in their capabilities compared to the others unless paired with an agent like Cursor, at least for now.

How Vibe Coding Impacts Product Managers

You could proceed with business as usual, ignoring vibe coding for quite some time, but if you're here, you want to be ahead of the curve. So here are some ways you and your team can leverage and get the most out of these tools now:

• Create rough prototypes - Great for creating rough prototypes and refining new ideas before presenting with design or engineering teams; think of this as your wireframe mockup, but fully interactive.

• Speed up development - Your developers may already be using the code-first version of these tools, tab completions, and the ability to get rough scaffolding done easily can significantly speed up development.

• Micro tasks - Trying to "one-shot" an application rarely works, although it might give you a good starting point. From there, you should limit each request to a well-defined and scoped change you'd like to see. Grouping multiple changes in a single request leads to poorer results.

• Code mobility - It's fine to start in Lovable, Bolt or another tool of choice, then export your codebase, and make the final touches in Cursor. Get the help of a developer if you need to put the finishing touches on your prototype.

• Build internal tools - Internal tools are often neglected or non-existent. Many product managers do product operations work, and AI coding is a great way to help you build internal tools to automate or streamline team processes.

• Test user flow variations - It can be hard to imagine what a dramatic shift in how your product works would feel. Now, you can create multiple variations that are fully clickable and even functional. Leverage these for user testing and validation.

We're still early; you don't need to become a vibe coder overnight. However, knowing about the tools and how they can fit into your workflow could give you and your team an edge. If you're already experimenting and not happy with the results you're getting today, try again in a week or two; the speed at which these things improve is truly remarkable.

Is it just me, or is it impossible to have a conversation with someone without it somehow becoming about AI? Just a few years ago, the dreaded 'A' word wasn't even part of most people's vocabulary, let alone the topic of the day.

Now it's AI this, and AI that. If your CEO isn't asking for AI-enabled product features, your customers surely will, and then there's the impending dread of finding out from an investor that your competitor came out with their own AI thing last week.

There is a lot of hype right now, I know. Some of you may think your product has nothing to do with AI and are reading or listening, thinking this is a total waste of time.

The truth is, AI is reshaping the landscape of product management (and every other role) faster than we've possibly ever seen. And it's not just about how you work. It's about what you work on, how you decide what to work on, and whether your current roadmap makes sense in a rapidly changing world.

Just two days ago, OpenAI released version 4.1, which performs significantly better in several areas and at a reduced cost. Suppose the previous model was too expensive for your needs or couldn't handle your tasks; that may no longer be a problem. If 4.1 doesn't meet your requirements now, wait a few weeks; someone will release another model that might.

When things change so rapidly, how do you plan for the future?

I've written before about Now/Next/Later and Outcomes-Based roadmaps:

• Now/Next/Later: Great for staying flexible. Prioritize in Kanban-style buckets and keep things moving.

• Outcomes-Based: Set goals like "increase conversion by 5%" and give teams autonomy on how to achieve them.

But here's the problem: In a world where goals shift every quarter (or week), how do you even know what will matter six months from now? Metrics are helpful, but they can quickly become outdated. It's never been more critical to stay focused on delivering value by solving real user problems.

Enter the Problem-Based Roadmap

If I could convince product leaders everywhere to do one thing right now, it would be to build a roadmap prioritized around user problems, not outputs or metrics. Many founders created their products to solve a real problem they saw. Somehow, a lot of us lost track of this point.

We need to go back to first principles and understand why your product or service exists in the first place and what problem it solves for users today. As I've taken on more side projects, I'm reminded of this again and again: Quarterly OKRs be damned; if you're not solving a real problem for real people, you're not creating long-term value.

So here's the bottom line: focus on the problem, but don't get locked into a solution because if AI can't do it today, it might in a week. And if you can leverage AI to help your customers solve their problems, great! But be prepared; they can, too, and they might not need you.

Why a problem-first approach works

A problem-based roadmap gives you room to adapt as the world shifts:

• Swap solutions in and out without blowing up your plan

• React to new AI capabilities, competitive changes, or market dynamics

• Align teams on the why, not just the what

And you can still layer structure on top of it. Start treating your roadmap like a Now/Next/Later Kanban, but for problems. What are the most pressing user problems we're solving now? Which ones are next? And which are worth paying attention to?

It's the same strategy for backlog management I've recommended for years: prioritize a few steps ahead and stay light on the details further out. In today's landscape, trying to spec work that's 3–6 months away is a complete waste of time. The tools will have changed by then, but it’s less likely the problem has (unless it's no longer a problem at all).

The Roadmap Reset

Traditional roadmap models don't hold up when everything is moving this fast. You need something that reflects the messiness of real-world decisions and the speed of change.

Let's recap the approach:

1. Ditch the fixed timeline: Adopt Now/Next/Later thinking.

2. Anchor everything to user problems: Not outputs, not even outcomes.

3. Use AI as a multiplier, not a crutch: It won't save bad ideas.

4. Re-evaluate constantly: Your best guess today might be wrong tomorrow.

5. Embrace the lone-wolf mindset: Be full-stack. Build, test, learn, repeat.

Because in this moment of rapid transformation, it's not about having the perfect plan. It's about staying close to the problem and being ready to change your approach the moment the world shifts again.

Let me know in the comments what you’re doing to keep your product roadmap flexible in a rapidly changing landscape. Not just when it comes to AI but also with tariffs and the rest of the uncertainty in the world today.

Leave a comment

Subscribe now

I've written several versions of this post over the past few weeks. Just when I think I've organized my thoughts on the matter and am about ready to publish, something new happens, and my worldview on AI is upended again with a groundbreaking new development or success story.

If you had asked me two weeks ago if AI was going to replace designers or illustrators, I would have said no, but with OpenAI's latest update to image generation in ChatGPT, I'm not so sure.

There are a lot of conversations happening around AI. How it's taking people's jobs, how it's creating new opportunities, how it's changing the way we work.

Even if you feel secure now that AI can't do your job, it's definitely going to have a significant impact. If nothing else, your future employment opportunities will look a lot different because of it.

Two days ago, the CEO of Shopify released an internal memo about AI. The expectation is that everyone in the company should be using AI now, and if you're looking for more headcount for your team, you must first demonstrate why you cannot get it done using AI.

I can confirm from my conversations with other PMs and company leaders, through coaching and training seminars, that if you're not using AI, there is a growing belief that they're not getting the full value for your time.

Some things to consider:

1. If your company has an enterprise-level GPT account (or equivalent), they'll be looking at usage statistics before the next round of layoffs. If you've never used it, you may find yourself at the top of the cut list.

2. AI is not going to replace Product Managers per se. AI can help you focus on strategic work. If anything, it will mean we need more PMs to manage the many more small and niche products that get created. If you're a developer reading this, I highly recommend investing in growing your PM skills.

3. I promise you, everyone hasn't figured it out already. I coach PMs from a wide variety of companies, and most are still experimenting. You're not late. You're early.

4. If you think things are moving fast now, they will only move faster from here on out.

Comparing current AI progress to the space race

The current AI boom is the next space race. In 1957 - The Soviet Union launched Sputnik 1, and just 12 years later, in 1969 - the US successfully landed on the moon with the Apollo 11 mission.

This AI moment might be even more significant and faster than that.

During the space race, the US government invested an equivalent of $318 billion in today's dollars into the Apollo missions.

In the last five years, venture capital has invested $334 Billion ($100 billion in 2024 alone, representing nearly one-third of all venture funding). The US government has promised its own $500 billion investment in partnership with OpenAI and other key partners, with $100 billion of that available immediately.

Between venture capital and government funding, the US will invest in AI, more than twice what was invested in the space race just in the next 5 years alone.

AI might be coming for your job as you know it, but I'm hopeful it's only coming for the parts that slow you down.

The Product Managers who thrive in this next chapter aren't the ones who ignore AI or even those who fully trust it. It will be the ones who treat it like a teammate: helpful, fast, sometimes wrong, but always getting better and making you better at your job.

You don't need to become a prompt wizard overnight or replace your instincts with outputs from a language model to stay ahead. But you do need to start experimenting. Try a few tools. Automate a few tasks. Let AI help you think bigger, faster, and with fewer roadblocks.

So start now. Start small if you have to. But start.

Leave a comment

Tomorrow is the first day of spring where I live. It's a season of new beginnings and a time when the physical landscape turns from a dull grey and brown to a lush green dotted with colourful flowers. It's like a hard reset for the landscape and a great time to be outside.

It reminds me of doing a hard reset on a computer or game console when it wasn't performing as expected (we still have to do this, but not as often).

In a similar sense of new beginnings and hard resets, software development has the phrase "nuke and pave," referring to the destruction of the current version and starting over.

You have probably heard engineers ask for this before, saying things like:

• "This is our chance to correct our past mistakes."

• "The previous team that wrote this is no longer here, and no one understands this code."

• "We've learned so much since building this version."

I've heard engineers get a bad reputation for suggesting what seems like such a drastic conclusion. However, it's often justified. Are you still using the same cell phone from 10 years ago?

Regardless, you can't deny what a great feeling it is to start on a new project without having to deal with the mistakes of the past.

But what if you wanted to start over from a product management perspective?

In Product Management, the equivalent of "nuke and pave" or a hard reset would resemble one of the following 15 strategies. In reality, many of these things could be A/B tests you run, but in some cases, the nuclear option is the best.

1. "Blank Slate Roadmap" - Scrapping your current roadmap and starting over, free from past assumptions or legacy commitments.

2. "Zero-Day Product Strategy" - Re-evaluating the entire product strategy as if you were starting from scratch, questioning everything from customer segments to the core problem you're solving.

3. "Feature Purge" - Removing legacy features, tech debt-driven decisions, or half-baked experiments that clutter the product experience and drain resources.

4. "Reboot the Backlog" - Deleting (or archiving) the entire backlog and only re-adding items that are still relevant and clearly aligned with the current business goals.

5. "Hard Reset" - A radical shift in priorities, often triggered by market changes, executive mandates, or failed execution that requires a complete restart. This usually means starting over with an entirely new product within the same market.

6. "Strategic Debt Payoff" - Just as engineers push to wipe out tech debt, PMs can advocate for eliminating strategic debt and past decisions that constrain growth due to outdated business models, pricing structures, or poor positioning.

7. "Kill Your Darlings" - Borrowed from writing, this means letting go of cherished but underperforming features, products, or strategies that no longer serve the company's best interest.

8. "Greenfield Pivot" - If a product or initiative is too bogged down by bad decisions, poor market performance, and no traction, shifting resources to an entirely new product space without the constraints of the past could be the answer. What the makers of Slack did is a classic example.

9. "Team & Process Overhaul" - Resetting how product decisions are made, eliminating inefficient processes, excess bureaucracy, and unnecessary rituals.

10. "Cancel every meeting" - Spotify famously did this with all recurring meetings of three or more people in 2023.

11. "Sunsetting the Zombie Product" - Your company might have a "zombie" product that still exists but barely grows, rarely improves, and is just a drain on resources.

12. "Pricing Model Overhaul" - Completely rebuilding the monetization strategy. Scrap your existing pricing tiers, switch from freemium to enterprise sales (or vice versa), or shift to a usage-based model.

13. "Customer Reset" - Reassessing your ideal customer profile (ICP) and target market from scratch instead of relying on outdated user personas or assumptions.

14. "Re-evaluate everything from an outcomes mindset" - Scrapping the existing feature-driven mindset and restructuring around customer outcomes may allow you to drop or simplify some existing features.

15. "Vision Refresh" - This is about rewriting the North Star to realign product, strategy, and company mission.

At some point in my career, I've taken nearly every one of these actions, and I've yet to regret it. It's great when you can let go of a few things and reduce the drag. Like a hot air balloon trying to take flight, the only thing holding your product back might be a few sandbags.

If you're going through or need a reset with your product and are looking for support, check out my coaching profile on mentorcruise.com. I still have a couple of spots left for next quarter.

Leave a comment

It really couldn’t be more clear… or could it?

Subscribe now

I’ve been coaching product managers for a few years and noticed a question being asked more frequently these days. The product managers I talk to want to make sure they’re doing product management the right way, wanting to know exactly how it is supposed to be done.

How do you talk to users? How often? What does a proper roadmap look like? Should I attend stand-ups? Is this the correct retro format? How long should my backlog be?

And of course, my answer is, “It depends”.

‘Doing product management’ means following a collection of processes, templates, and actions, but what are the correct processes, templates and actions to follow?

Similar to our ideal way of building products (iterative, data, and feedback-driven), we should also acknowledge that how we ‘do’ product management must evolve and change over time and according to the situation.

Like much in life, there is more than one way to do things, and product management is no exception. The best methods will depend on the situation, including the culture, existing tooling and processes, and your level of influence in your company.

These variables vary greatly for each of us.

The messaging from many of the loudest voices in product management can seem dogmatic about how the role should be done (and far too high-level). In reality, I know many of you reading this are not in a position to reshape the way your company does product management and have been handed a mixed bag of tools and responsibilities. How ‘you’ do product management will come down to your ability to work within existing processes, change or influence what you can, and discover what gets things done where you are.

Whether you’re following certain processes or using a specific template shouldn’t be your measure of success. You probably can't change these processes unless you’re at the Director level or above. Instead, you should measure your success by the results you can get for your users and the business.

So, to those of you who have been doing product management for a while but lack the ‘formal’ training you think you need, you probably know more than you realize, and rarely is there going to be a ‘right’ way to do it.

On the other hand, if you are in a position to influence or change the processes that dictate how product management works in your company, here are a few things to consider.

How to determine if we’re practicing the ‘right way’ of working:

You can improve your process a lot like you’d improve your product. It’s helpful to take an iterative, data-driven approach.

Evaluating current processes:

• Are people following the process or working around it? If a process is routinely ignored or worked around, it’s a sign that it might be too complex, bureaucratic, or just not benefiting your team. Desired paths may already exist, and it could be worth evaluating those rogue processes as alternatives.

• Are we defaulting to the way we’ve always done things? Just because a process has been in place for years doesn’t mean it’s still effective. Regularly challenge assumptions about what’s working and what’s not.

• Are we seeing meaningful results from our current approach? If your existing process is helping the team ship valuable products, collaborate effectively, and meet business goals, it may not need changing, just refining.

For every process, new or old:

• Does this process improve decision-making or add overhead? A process should enable better, faster, and more informed decisions. If it slows things down without adding real value, it’s worth reconsidering.

• Who benefits from this process, and who bears the burden? A process that disproportionately benefits one team while making others work harder may create friction and resistance. Look for balance.

• Are we including the right stakeholders at the right time? Too much input can slow things down, while too little can lead to surprises later. The right balance is key.

• Does this process create unnecessary dependencies? If a new process forces teams to wait on approvals or input that isn’t truly needed, it may be slowing things down without good reason.

• Is this process scalable and adaptable as we grow? Some methods work great for a small team but become a bottleneck as the organization scales. Consider whether it will evolve with your needs.

Things to consider before you add a new process:

• Are we adding processes for the sake of processes? Every process adds some level of complexity, and if deemed unnecessary, people will steer away from it. Consider adopting a guideline instead of a formal process.

• Do we have evidence that this process has worked elsewhere in a similar context? A process that works at a 10,000-person company may not be effective for a 50-person startup. Look for examples of successful implementation in similar team sizes and business models for an idea of how to adapt it to your organization.

• Are we treating this process as an experiment? Instead of committing fully upfront, consider testing a process change on a smaller scale before rolling it out across the organization.

• How will we measure the impact of this process? If a process change is meant to improve efficiency, collaboration, or decision-making, ensure there’s a way to track whether it’s delivering on that promise.

Product management can be messy. It’s one of the least straightforward roles I’ve ever had, full of ambiguity and uncertainty at times. Your goal is to work through that and find clarity to bring to those supporting you.

If you’re looking for help or support figuring out how to do product management where you are, coaching can be a great option. Get feedback tailored to you and your situation, and learn how you can improve your existing processes, even if you don’t think you have the influence to make it happen. Checkout my coaching profile on mentorcruise.com.

Share

Have you ever thought to yourself, "Maybe I’m just a bad product manager?" You could be feeling overwhelmed and like you’re not making progress. Maybe you haven’t seen a win in a long time, and that’s when the self-doubt starts to creep in. Staying positive can be a real struggle when there is so much negativity like many of us are seeing right now.

Layoffs have hit the industry (again). Whether you were one of those let go or someone left to pick up the pieces, these challenging times can shake the confidence of the most self-assured of us.

But even in the best of times, I’ve had jobs I’ve excelled in and others where I’ve struggled. Even as I’ve gained more experience, there have been times when being good at product management felt like an uphill battle.

Sometimes, it comes down to the economic environment, the team, the processes, the company’s growth stage, or just how little agency you actually have to change things. You may be doing everything ‘right,’ but your product or company is still struggling.

Feeling this way doesn’t mean you’re a bad product manager.

Subscribe now

If you’re questioning or doubting yourself, you’re not alone

Honestly, even in the past week, I’ve doubted my ability as a product manager more than once. It can be easy to question your skills and abilities, and the more senior you become, the bigger the challenges you can face. My company let go of some great people a couple of weeks ago, and there have been a lot of market forces limiting our growth.

Here’s the thing: you care! Otherwise, you wouldn’t be asking yourself these questions. And if you’re here, then I know you’re already putting in the work to avoid being a bad product manager. So, chances are, you’re already a good product manager.

In reality, you won’t get it all right every time. When things in your company are going well, you might feel on top of the world and dropping the ball on a few things might not feel like a big deal. Still, when metrics tank and revenue targets are missed, it can be challenging to know how much of that was within your control vs. out-of-control economic factors, and when layoffs have you in their crosshairs, it can be hard not to take it personally.

Chances are you’re not the only one feeling uncertain. Check-in with your teams; they’re probably feeling the pressure to perform, too.

If self-doubt is creeping in, here are a few things you can try to boost your morale:

• Focus on your past wins and key something up for the near future.

• Zoom out and look at the bigger picture. Is your team the only one struggling?

• Connect with other PMs, join a product community, attend a conference, or find a mentor.

• Review your day-to-day. Are there meetings you shouldn’t be attending?

• Ask your peers what you’re doing well; focusing on the positives can help.

• Discuss with your manager what support you need to do a more effective job.

  • It’s possible your manager thinks you’re doing great or doesn’t realize you’re struggling

  • Note the obstacles holding you back from doing your best work.

• Become laser-focused, prioritizing higher-impact work while letting go of lower-impact tasks.

• Take some time off, a mental health day, a vacation, and find a way to recharge.

It’s not about getting everything right all of the time

In the fast-paced world of product management, you will never be perfect. And in reality, your company likely cares about one thing: generating revenue. If you have a growing user base and the company is hitting revenue targets, everything feels great, whether that success is due to skill, timing, or luck.

Right now, though, many companies aren’t hitting their numbers. It’s important to realize that you could be doing everything right, which might still not be enough.

You may do only one good thing in the next year, but that thing saves the company. Would that make you a good product manager?

Maybe you really are a bad product manager (but probably not)

Here are some ‘bad product manager’ habits to avoid:

• Ignoring customer feedback.

• Being reactive, chasing every new request without considering the long-term strategy.

• Overriding engineering or expert decisions without good reason.

• Not communicating clearly or at all.

• Not sharing the credit.

• Having no strategy.

• Ignoring the data.

Dropping the ball on one or two of these doesn’t make you a bad product manager. Most of us are overworked and stretched thin, which makes mistakes inevitable.

The key is to recognize where you can improve and keep going. Because caring about whether you’re a good product manager is already a sign that you’re on the right track.

Share

The SCRUM guide will tell you, that after each sprint there is a sprint review and retro followed by planning for the next sprint. If you take it at it’s word, you’d be forgiven for thinking that’s all that happens after the sprint, but you’d also be missing out on crucial opportunities and overlooking some critical steps in the process.

There is a lot more you should be doing near the end of the sprint and once the sprint is finished. Here are a few of the less frequently talked about things you should be focusing on:

• Burn down charts

  What gets measured gets done. Burn down charts help highlight bottlenecks and show where work is getting stuck. If your team isn’t tracking progress, you’re flying blind.

• Product marketing

  Now it’s time to tell your customers what you spent all sprint building! Ideally, you’ve already got a go-to-market plan, but this is when you refine messaging with Marketing and get the word out.

• Communicate outcomes to stakeholders

  Your stakeholders need to know what was accomplished, what’s launching, and what’s next. Keep them informed and engaged.

• Celebrate the wins

  Too often, we just roll straight into the next sprint without taking a moment to recognize what we’ve achieved. Celebrate the wins, big or small. It helps morale and reinforces a culture of progress.

• Customer support and success

  Do these teams have everything they need to help your users be successful with what you’ve built? Have you changed things that they, and your customers will need to know about?

• Learnings and future improvements

  Did you or the team learn things during the sprint that are valuable inputs to future work or should be noted somewhere? There may be documentation about how something works, or a learning to apply to the next iteration of something you’re building.

• QA and bug triage

  Even though the sprint is over, there may still be some bugs, or unfinished work that should be dealt with. Do you have a process for managing, triaging and tracking this work?

• Release & deployment

  Not everything built in the sprint goes live immediately. Covering post-sprint release planning, feature flags, phased rollouts, or monitoring for issues all have added complexity.

A lot of these activities are time-boxed to the end of a sprint, but there are a few more that live long after the sprint is over. Some of these ongoing tasks are:

• Gathering user feedback

  What do your users think? How is the feature performing? This is where you validate assumptions, gather insights, and plan for improvements.

• Impact measurement and follow-up

  How is the feature performing? Is it having the impact expected? It’s important to continue monitoring performance, not just of this feature, but potentially how it impacts other user behaviours. What’s the follow-up to this feature?

• Paying down technical debt

  The more complexity added to your product, the more technical debt and overhead costs your team has. It’s important to be aware of this, and plan ways to address this through paying down technical debt, additional headcount and more specialized teams.

The sprint might be over, but the work doesn’t stop. How your team handles what happens after matters just as much as what’s happening during the sprint.

Need a refresher on sprint planning? Check out my posts on sprint planning and what happens during the sprint.

Subscribe now

Share

To those that know me, it’s no secret that I have a bit of an addiction to learning new things. I frequently have new hobbies and often spend a year or two becoming consumed by them before getting bored and moving onto the next thing. In the past 20 years alone, I’ve learned so much about so many topics that it’s entirely possible I’ve forgotten more than many people learn in a lifetime.

I get a little obsessive with these things, like when I learned to make pizza. I experimented with and changed my dough recipe and cooking technique every Friday for over a year until I achieved perfection. By the time I stopped, my kids were sick of eating pizza. Similarly, I’m improving my writing with this newsletter, and by making this public, I have some accountability which is why I’ve been able to stick with it for nearly a year and a half.

I can’t get enough of learning. Here are some of the things I’m currently learning or working on improving my skills around, and let me tell you, I should definitely take some of my own advice with a couple of these that I’ve fallen behind on:

• Spanish

• Game development

• Writing

• Drawing

Something that’s easy to overlook as part of the iterative learning process, are goals and a strategy for improving your skills. Much like a product, this means having a roadmap for your learning. This syllabus, learning plan, or learning roadmap will help you stay focussed and ensure you’re getting a grasp on the basics. Keep reading to the end of this post for a free prompt you can use with your ChatGPT of choice to help you build your learning roadmap.

Steps to keep learning manageable

Here are some things to consider if you want to ensure your personal and career growth are not an afterthought:

• Free up time to work more on your skills development. This could mean extending your lunch break, replacing another activity for a while, or multi-tasking.

• Set time-bound goals and objectives for yourself.

• Make it a habit if you can; keeping a consistent schedule will help you stay on track and avoid forgetting to put time into what you’re learning.

• Frequency over duration. For many things, 10 minutes a day or an hour a week is better than 4 hours at the end of each month.

• Hire a coach or teacher to help guide you and keep you accountable. This can be a great shortcut and help you get through some of the plateaus you’ll experience.

• Engage in continuous learning through books, courses, podcasts, or webinars related to the subjects you’re committed to learning.

• Mentor or coach others once you’ve reached a base level of knowledge. This will help you cement your existing knowledge and push you to fill any gaps you may have.

• Reflect on failures and successes with learning progress retros. Evaluating your progress and adjusting your plan to meet your goals is important.

• Seek feedback from peers and mentors.

• Participate in communities or forums. This can be a great way to get feedback, hold yourself accountable, and be inspired. Just be careful not to compare your progress to that of others.

If you’re not sure where you should start learning, you can build a matrix of your current skills and evaluate growth opportunities. See my free skills matrix and learning plan template:

Common pitfalls to avoid

There are some common struggles I see and have experienced personally:

1. Not being focused enough on the current goal or having too many priorities.

2. Not spending enough time and being infrequent with your practice.

3. Not being intentional with your practice.

   1. This could mean not having clear and attainable goals.

   2. Shallow learning without giving it your full attention.

   3. Passively repeating the same things hoping you will get better.

   4. Or, trying to learn it all at once without a clear roadmap or process.

Let me give you an example. I know someone who loves art and has been drawing and painting daily for years. However, their progress has been very slow. Here are some of the things I see them doing that are limiting their progress:

• Spending days on a single, very complex drawing while trying to get every detail perfect.

• Painting that exact drawing without any exploration or even transferring it to a new canvas.

If this person were to take a step back and build a learning roadmap or syllabus, they’d be able to make far more progress. It’s important to consider what you need to learn, and in what order to build on prior knowledge.

What our artist friend above should be doing instead:

• Breaking down the complexities of something like painting. Learning to paint means learning:

  • How to paint light and shadow.

  • Mixing paints and understanding colour relationships, tone and value.

  • Experimenting with different brushes and brushwork techniques.

  • Learning to work with different mediums like watercolour, which is very different from oils or acrylics. Digital painting also has its quarks. It’s probably best to pick one to focus on before moving on.

• They should take a similar approach described above to improve their drawing fundamentals before moving on to painting. If you can’t draw what you want, it will be hard to get the results you’re looking for in a painting.

You could break down learning to paint into 20 or more key topics across many different phases of learning development. Once you learn some of the skills above, you’ll also need to learn and practice the typical painting process:

• Ideation and planning

• Rough sketches and thumbnails

• Value study

• Colour study

• Working in layers

If you want to break the rules and work outside the norms, experts will insist that learning all of the basics of a skill is still a must. I generally have to agree.

What to do when you’re stuck

If you’re feeling stuck in your progress, re-evaluate your learning roadmap and objectives. It can be helpful to go back to basics for a while. It’s important to remember that plateaus exist, and you will often hit a ceiling in your learning, especially after you grasp the basics.

A couple of books I recommend that will help get you in the mindset needed to push through these plateaus and encourage you to continue learning new things:

1. Outliers - by Malcolm Gladwell

   Well known for the 10,000 hours rule, Malcolm Gladwell interviews Bill Gates and explores the factors that contribute to high levels of success, such as opportunity, cultural background, and importantly, practice.

2. Peak - by Anders Ericsson

   Ericsson is responsible for the research that led Malcolm to embrace the 10,000 hour rule. Peak expounds on the remarkable adaptability of the human brain and how 'deliberate practice' allows us to master new skills and abilities.

And, as promised, here’s a prompt to get you started on creating your own learning roadmap:

Subscribe now

Share

Prompt 1: High level, 5 to 10 step plan

You are an expert in instructional design and skill development. Your task is to create a simple, actionable learning plan for someone who wants to learn [INSERT SKILL] from scratch. The plan should be easy to follow, practical, and adaptable for self-learners.

Instructions:

- Create 5 to 10 clear steps that guide the learner from beginner to proficiency.
- Each step should focus on a key milestone or fundamental concept.
- Keep instructions simple, avoiding unnecessary complexity.
- Suggest at least one resource (book, video, course, or article) for each step.
- Include practical exercises or small projects to reinforce learning.
- If relevant, recommend a way to track progress or get feedback.

The final plan should be concise, motivating, and easy to implement without requiring multiple learning phases.

Prompt 2: More detailed learning plan with timelines

You are an expert in instructional design and skill development. Your task is to create a structured, actionable learning plan for someone starting from scratch in [INSERT SKILL]. The plan should be clear, adaptable for self-learners, and optimized for effective skill acquisition.

Instructions:

1. Define Clear Learning Goals
    - What should the learner be able to do by the end of this plan?
    - Focus on measurable skills and real-world applications.
2. Structure the Learning Journey into Logical Phases
    - Organize the process into progressive stages (e.g., Beginner, Intermediate, Advanced).
    - Briefly describe the focus of each phase.
3. Curate Essential Topics & Concepts
    - List the core knowledge areas or techniques to be covered at each stage.
    - Prioritize foundational skills before advancing to complex topics.
4. Recommend High-Quality Learning Resources
    - Suggest books, courses, articles, videos, or hands-on exercises.
    - Prioritize accessible and up-to-date resources.
5. Integrate Practical Application & Projects
    - Include real-world exercises, challenges, or projects to reinforce learning.
    - Provide examples of how to apply the skill in different contexts.
6. Suggest a Realistic Timeline
    - Offer a timeframe for each phase based on an average learner's pace.
    - Consider flexibility for different learning speeds.
7. Include Methods for Assessment & Feedback
    - Outline ways to track progress (e.g., quizzes, self-assessments, peer feedback).
    - Recommend strategies for continuous improvement.

Additional Guidelines:

- Ensure the plan is engaging, self-paced, and adaptable to different learning styles.
- Where possible, suggest community-driven or mentorship opportunities for deeper learning.

Much like the shift to full-stack for developers, the meaning of “full-stack” will be pushed to more extremes. Many developers must know front-end, back-end, database, system architecture, DevOps, and Data Analysis, but it wasn’t always that way. For product managers, this skillset expansion will result in lone-wolf, full-stack PMs who do everything, from designing and building a prototype to launching and evolving it.

In my coaching, I’ve worked with some traditionally non-technical PMs who are managing releases, writing QA tests, and building prototypes on top of their regular duties. Traditionally, early-stage startups might forgo product management roles altogether, but we’ll likely see more full-stack product managers at every stage of company development.

Product management is already a multi-disciplinary role, so what does it mean to be full-stack? Full-stack means you can contribute to all stages of a product’s development from inception to launch (traditionally not including development). You possess a Swiss Army knife of skills from technical know-how to data analysis, design, go-to-market, revenue management, etc.

Isn’t that enough? Well, to be a lone-wolf, full-stack product manager, you also need to:

• Design and prototype with minimal support.

• Get market traction with the prototypes you’ve built.

• Scope and plan the building of the production version.

Along with everything previously mentioned.

There are many reasons why I think this will happen, but mainly, the shift is driven by the “do more with less” mantra most companies have adopted, which has been made possible by some of the latest technical advancements and market shifts. Some of these are:

• An abundance of senior tech people:

  The more senior you are, the more chance you’ve had to work multiple roles and build your skills across various stages of business. It’s rare to get into product management without having spent a decent amount of time in another role or at least having some expertise in other areas. Product management is a likely place to start if you’re an engineer or designer recently laid off and looking for a change.

• Simplification and democratization of design and development toolsets:

  Tools, processes and systems are converging and standardizing. Most off-brand tools follow the same patterns, shortcuts, and processes as their mainstream counterparts. There are GUIs for most command-line systems and one-click setups for most other things.

• The growing power of AI and automation tools:

  Have you heard that the first Billion-dollar single-person company is around the corner? That’s partly thanks to the advancements in AI. People can get more done now than ever with a cursory understanding. So why hire data analysts, researchers, designers, and developers if you can hire one person to do it all?

• Improved toolsets for prototype development and publishing, such as:

  • Cursor’s agent mode, which can turn a PRD into an entire application within seconds.

  • One-click publishing and deployment to the cloud options are available for most infrastructure-related tasks.

  • Pre-built design systems and frameworks that eliminate a lot of the boilerplate.

• Lack of available funding:

  Many companies have adopted a ‘do more with less’ mentality. Combine this with the advancements in AI I just mentioned, and companies everywhere are expecting everyone (not just product managers) to take on more responsibilities (often at the same or less pay) to help them hit their targets.

This doesn’t just apply to product management; I also see it happening in other roles. Here are two examples just from my immediate network:

• I work with a marketing manager who has coded an internal tool to manage GDPR compliance and connected custom data feeds into email systems to improve campaign targeting capabilities.

• Commercial salespeople at my company are learning SQL and pivot tables so they can accomplish more independently without waiting on constrained resources elsewhere in the company.

While writing this post, I came across a guest post by Colin Matthews in Lenny’s newsletter, which illustrates my point even more. AI prototyping is now something anyone can do, and it will only improve from here.

What do you think? Are you experiencing a flattening of roles and having to take on more responsibilities as a product manager? Is this just a fad, or is it a trend we should be prepared for?

During the sprint, your engineers pull tasks from the sprint backlog to work on. As they do the work, they might have further questions about it. Design work may still be required, and disagreements or challenges may arise.

Have you been in this scenario? The sprint ends, and your QA team starts testing everything before the push to production. Several features are ready, but a priority zero bug has been found in one. Fixing it is expected to take at least a day, but the engineer who developed it is on vacation until next week. The next sprint has already started. Disconnecting the feature is complicated as it affects many parts of the application. The entire release is now delayed since you can’t have users experiencing this bug. The engineering team can work on it, but it may take three times longer. It’s better to wait for the developer’s return.

You’ve probably seen this happen before. Several things are going wrong in the situation above, but they can usually be solved with a few process changes:

• QA is happening too late in the process.

  • Solution: QA earlier, as work is being finished. Involve engineers in the process. Finish development work a day or two early to allow time for everyone to bug hunt and put the polish on the release.

• Your team is dependent on a single engineer/developer.

  • Solution: Cross-train, pair program, or whatever it takes for others to become more familiar with what their team is working on.

• If one thing is broken, nothing can be released.

  • Solution: Leverage feature flags, and do your best to plan features so that they can be enabled or turned off independently. This would also benefit you by enabling the roll-out of features to a set of BETA testers for real-world feedback and testing before going live with all users.

Some common sprint problems and how to avoid them:

The QA team is a sprint behind your engineering team.

• This happens when QA is left until the end of the sprint. Your QA team should write automated tests where possible and be testing work as developers finish it. You might need more QA testers, or you may need to take on less work each sprint to improve quality and reduce bugs.

Many stories are staying open for an entire sprint.

• It’s likely your stories are too big. Leverage concepts like the smallest functional slice and push for better estimations during sprint planning.

Engineering only gets half of their work finished.

• A few things could contribute to this: either they were severely oversubscribed, estimates were off, some blocker was preventing them from getting work done, or there was a lot of unplanned work that happened. You need to get visibility into the work and narrow down the possible causes. It's time for a retro!

Nothing is ready for release, and everything is half-done.

• This could be a sign of too much work in progress. Ideally, engineers are finishing one task before moving on to the next. The opposite can happen for a variety of reasons:

  • Engineering gets blocked on a story

  • Stories are not standalone pieces of work and have multiple non-linear dependencies.

  You can resolve this by adjusting the scope to meet the sprint goal, breaking stories up into vertical slices instead of horizontal ones with many dependencies, and adding a work-in-progress limiter to your project management software to help flag the issue earlier.

The last sprint’s work was buggy, and now you’re spending this sprint fixing bugs.

• This can happen when all the testing is left until the very end of the sprint. You can help alleviate this by doing QA on work as it’s finished, writing automated E2E and unit tests, and having developers review each other’s work.

There are missing features or capabilities despite stories being marked complete.

• Take a moment to review the acceptance criteria for that work. Are they clear? You may need to be more specific, include more detailed designs, or spend more time talking with engineering about the work while having more of an open feedback loop.

Engineering is blocked by design.

• Spikes and design tasks a sprint or two ahead of time can help alleviate the design bottleneck. Ideally, you’re coming into the sprint with a detailed plan for doing the work already committed.

You feel like there’s no visibility into progress until the end of the sprint.

• A mid-sprint review meeting can be a helpful pre-demo meeting to review the work completed up to that point. It can also be an excellent opportunity for feedback, course correction, and cutting scope to meet deadlines.

If your teams are struggling with some of the above, feeling overwhelmed, and genuinely feeling like they can’t get caught up enough to solve any of these challenges, then it might be time to have a cooldown sprint. Instead of assigning new feature work, everyone should work on getting caught up on bugs, fixing the technical debt, building QA automation and getting caught up.

Remember, you’re not alone in solving these problems. Work with your team to help narrow down the issues and refine your process. Sprint retros can be a constructive way to get alignment and drive solutions. Follow my 7 steps to a good retro to ensure you get the most value.

What other common challenges do you see teams struggling with? Do you have a unique situation that might call for an even more drastic approach? Reach out for some one-on-one coaching for a tailored solution for you and your team.

Subscribe now

I’m not prescribing a specific way of working, and when it comes to Product Ops, what works best will depend on the many factors your company and teams are dealing with.

At my current company, we don’t have sprints, and we don’t use project planning software. Regardless, we still have backlogs, and there are some general principles you can follow here if you, too, have a backlog.

It’s not sexy, but now and then, we product managers have to prioritize backlogs and write user stories with acceptance criteria. Whether you believe this should be part of a product manager’s job or not doesn’t change the fact that this responsibility often falls to product managers within many companies, especially smaller startups, where there often aren’t separate product owner roles.

Step 1: Avoid having your backlog become a wish list

As this is just part of our job, keeping the work from spiralling is important. Product backlogs can quickly become a never-ending to-do list of nice to haves, bugs, customer requests and those shoes you bought, totally intend to wear, but they never really fit right, so they just sit there taking up space in your closet… and in your mind.

That’s one reason why backlogs become such a dumping ground: everyone needs somewhere to put their ideas, and everyone wants to feel heard. If they don’t put them there directly, they’re telling you, and you’re adding them.

Enter a service like Product Board (not sponsored), Intercom, or similar that helps with collecting ideas because this should happen somewhere other than your backlog. Your internal and external feedback can get tagged and eventually turn into a list of ideas. The benefit is you get the raw feedback, not just the “solution,” and if done right, you may even be able to follow up with individual customers for clarification.

Ok, we’ve cleaned up some of the backlog, but how do you prioritize what’s left?

Step 2: What’s in a backlog?

You might already be a pro, but for the rest of us, let’s cover the basics so we’re all on the same page:

• Epics (Features) - A collection of user stories that often stretch across several sprints.

• Stories - A chunk of deliverable work, ideally a functional slice, but not always.

• Tasks - The things engineers do to get the work done.

And within Stories, we typically find:

• User Story - Often phrased like “As a [user], I want to, so that,” this should give your team their why.

• Acceptance Criteria - The functional capabilities of the user story, i.e., the user is redirected to home page after login

• Definition of Done - Ideally, this should be part of your story template and include pre-agreed criteria for what constitutes done where you work, i.e., unit tests written, metrics tracking integrated, deployed to staging.

One place you may be able to save some time, is the Epic. I find it helpful to structure this like a PRD, and in some cases, it serves as your PRD. It’s important to include details like:

• Business Value

• Goals / Outcomes

• Problem Statement

• Scope

• Functional & Non-Functional Requirements

• Risks and Assumptions

Because it’s an Epic in JIRA or similar software, you also conveniently get:

• Timelines

• Dependencies

• Breakdown of Stories

• and Estimates

Suppose you need to communicate these details to other stakeholders. In that case, you can conveniently link them to a Google Doc leveraging capabilities like JIRA smart chips, which stay synced with JIRA to show the status of each story and a tool like Zapier to sync the contents of the epic for your PRD. If using Linear, you can get similar functionality within Notion.

Having your project management tool serve as the source of truth helps limit the number of places you’re updating this information.

Step 3: Prioritize your backlog

Just like it’s tempting to add all your ideas to the backlog, it can also feel like you need highly detailed epics and stories looking months ahead. I prefer to plan the details a sprint or two ahead and have less granularity or detail the further I look. Beyond that, you might only have epics and no stories. It becomes more of a now, next, later prioritization and should only have some high-level effort or confidence estimates (small, medium, large).

This means you might know we’re working on improving customer onboarding sometime next quarter, and although you have some ideas of where that user flow needs improving, you don’t yet have detailed designs or engineering specs. Planning this work months or quarters in advance is not helpful because a.) people will forget the plan by the time you do the work, and b.) everyone having that much context about things that are months away distracts from the work at hand.

Step 4: Planning meetings

I’ve worked at companies with half-day sprint planning meetings, and a lot of that came down to product management not having enough details about the work. Rather than getting some details, reworking the problem, and then coming back for planning, we’d do the rework right then and there. It was highly inefficient.

This is why I typically suggest having a pre-planning meeting first. This would be a mid-sprint meeting to review what you’ve prioritized for the next sprint. This gives you a chance to get engineering feedback, reevaluate priorities based on said feedback, and know where the gaps are. Generally, there’s no estimating being done here, and it can be an hour-long meeting. Anything that needs to be discussed in more detail can be done in a separate meeting, or a-sync, with just the relevant people.

This means that by the time your actual sprint planning meeting comes around, you’re much better prepared, and after reviewing a few of the changes, you can jump into estimating. This meeting should also be no more than an hour.

Step 5: Estimating

Unless you have a standardized process for doing something, it’s unlikely you can truly know how long it will take to complete a specific user story or epic. Estimates should happen only once the work is well-defined and shortly before a sprint. This is because things can change month to month, and what was easy six months ago could become much more complicated because of changes in the product, or it could be far easier now.

Avoiding time estimates is a good rule of thumb here, and focusing on complexity/effort gives you much more flexibility. Many studies have proven that blind group estimates produce a realistic average (if given enough people), and there are a couple of planning poker tools that can help with that; see included links:

• https://deniz.co/slack-poker-planner/

• https://pointingpoker.com/

A Fibonacci sequence is generally accepted, but so is T-shirt sizing. Regardless, aligning the team on what this means is most useful. I prefer to define it like this and have found doing so removes a lot of uncertainty:

• 1 (or small) - I could write the code with no assistance and have it on production within a day or two.

• 2 (medium) - Stack Overflow or Cursor AI might help, but I generally know how we can do this.

• 3 (large) - This requires some planning, maybe some architecting, and there are parts we’re unsure of.

• 5 (extra large) - There are significant unknowns. Breaking the task down into smaller parts can isolate those unknowns and lead to better estimation.

• 8 (extra extra large) - “I don’t know how we’d do this.” Something this large needs a research spike and likely needs to be broken down into smaller pieces.

Hopefully these 5 steps are a helpful start to getting your product backlog back on track. You may already be doing some of these things well within your organization, but hopefully there were a few takeaways you can leverage to improve things even further. With the right approach, backlogs can become a useful way to prioritize and plan what your teams are working on next.

Subscribe now

What a year 2024 was. I hope you’ve enjoyed getting acquainted with Roadmap Weekly this past year, whether you’ve been here since the beginning or just recently subscribed. I know I’ve enjoyed writing, and I am proud to say I’ve succeeded in completing my first full year of Roadmap Weekly posts!

Since then, I’ve covered everything from roadmaps, metrics, funnels, AI in product management, product manager superpowers, your first 30 to 90 days in a new role, stakeholders, entropy, and more.

If there’s a topic you’d like me to cover, let me know in the comments!

2024 Highlights

Last year, I had the chance to be on a video podcast where I discussed the impacts of AI on the product manager role. You can watch and experience the whole thing here:

• Note: I really dislike being in front of the camera, I spent nearly a decade as a photographer on the other end for a reason! 2025 is the year I overcome my discomfort in front of cameras!

My top 5 posts this year (by number of views):

#1

• This one got picked up by Google Discovery and garnered over 1,300 views in just a couple of days! These are five of the greatest product-related books I’ve ever read, and they’ve impacted the core of how I think as a product manager.

#2

• Work is hard, and managing chronic illness or disability accompanied by chronic pain doesn’t help. If you’re also in this camp, you’re not alone; it’s possible to have a successful career, but sometimes our definition of success needs to change.

#3

• Whether it’s your first day as a new PM or you’re starting a new role at your current company, these first 30 days are critical, and I have some tips on how to make the most of them based on my own experience and the advice of a great book.

#4

• I was going to say that 2024 has been a rough year, but so was 2023 for many of us. So, what does 2025 hold in store for someone wanting to continue on the path of a career in product management?

#5

• An essential responsibility of product managers is to deliver value to our customers. If this isn’t happening or is happening on far too long a timescale for your industry, your top priority should be fixing those value delivery challenges. This post illustrates why early value delivery is so important.

What’s coming in 2025

I’m excited about the posts queued up already for 2025, so I hope you’ll stay tuned and spread the word so no one misses it. Here are just a few of the posts coming your way:

• How to prioritize and work with your product backlog efficiently

• Managing the sprint: From idea to delivery

• Retros revisited: how this often overlooked meeting brings value when done right

New: Courses

I’m also working on a couple of courses. I’ll rework my current writing into an easy-to-digest format, using a mix of text, video, assessments, and templates, making them available to paid subscribers on Substack.

I already have two courses in the works: one on Road Mapping and the other an introduction to product management. For a sneak preview of the courses and their course outlines, have a look at the Guide to Roadmapping.

I hope 2024 has been a good year for you. I believe 2025 has great things in store.

So, from me to you, I wish you a Merry Christmas and a Happy New Year!

I started Roadmap Weekly because several product managers asked me the same questions during my first two years moonlighting as a product management coach. Many of their challenges were universal. In one way or another, these people were going through similar struggles. I had gone through them as well. Thankfully, I was able to get through those challenging times, and I was able to guide those mentees successfully through their challenges as well.

Some of my processes were unorthodox, but a couple of product managers tried them to great success! At this point, a couple of years into coaching, I had the confidence to start sharing my thoughts on product management through this Newsletter.

That was nearly 15 months ago. Since then, I’ve experienced many new challenges as a product manager, as I’m sure you have. Whatever your struggle, please know that you’re not alone (even though it may seem like it, product management can be a very isolating role). There is a wealth of community knowledge with many others who have gone before us.

My Christmas gift to you is to continue writing Roadmap Weekly. I hope you’ve enjoyed reading it as much as I’ve enjoyed writing. Truth be told, I would still write this newsletter even if just one person were reading it. Thank you for a great year, and I wish you all the best for 2025!

• Spend weeks or months agonizing over what to build

• Spend months building something without getting feedback

• Launch the thing to find out it’s not what anyone wanted in the first place

So, how do you know what to build? If even the best plans can fail, how do you improve your chances of success? In short, you just need to try more things.

I’ve recently been re-inspired by Facebook’s testing philosophy. Years ago, Boz (Andrew Bosworth) wrote about it on their engineering blog. I read about it then and later heard about this rapid testing process from other companies like Netflix and Amazon. I’ve worked hard to implement this at several companies and on a few projects. It can be a difficult transition, and creating the safety to do this can require a massive culture shift.

But good products aren’t built in a vacuum. The feature you think will be impactful could completely miss the mark. That thing everyone is convinced will never work; it may just be your golden ticket.

I’ve tried to drive this culture of testing wherever I’ve worked. When I was the Head of Product at a small tech startup, pushing us in this direction was easy because I didn’t have to convince many people. In larger, more established companies, it’s been far more challenging, especially without the same level of seniority.

Many businesses think they’re adopting a culture of rapid testing, but they’re a long way off. Sometimes, it’s because they’ve never really seen what’s possible. Maybe you’re in a similar situation. Your company may be content with launching new experiments every few weeks or months and think this is top speed. They don’t realize it’s possible, and maybe even essential, to launch several experiments per day.

This doesn’t apply to every feature. It might be hard to get a test out today for a new login integration or a new self-serve cancellation flow. However, there are still ways to test those things and get real-world data today through concepts like pretotyping. See Alberto Savoi’s resource from his book, The Right It.

However, if you manage a user funnel, you should definitely test everything you can. That applies to marketing, SEO, and sales funnels, too.

By now, you’re probably thinking, “This is great, but you still haven’t told me how I can know what to test.” First, let’s discuss what a test looks like, and then we can review some things you can think about to help generate test ideas.

Here is an idea of what a test could be:

• Changing the primary colour of our search button: In my current company, a simple colour change to our search button caused a six-point drop in search completion. Making that same button dynamic (active only when the search field changes) brought us back to our baseline and generated an additional three-point increase in search completions.

Here are some things you can try:

• The Reverse Test: Test turning it off; there may be things you can remove

• Simplify and combine: Test removing form fields, steps in a process, number of options

• The default test: What is the default setting? Try changing it in every way imaginable

• Split it: Make one section into two, or create multiple steps from a single screen

• Change the design: Make a text link a button, change text size, colour, shape, imagery

• Text: Different copy, new messaging, new button text.

• Layout: Move it up the page, down the page, try a 2-column or 3-column layout

• Communicate: Better communicate to users where they are in a flow, what the next steps are, and what just happened when they clicked that big red button.

You can still leverage existing data to inform your tests. User reviews and conversion performance at various stages of your funnel can point you in the right direction. But, in practice, users rarely tell you explicitly that a button needs to be a different colour or that the layout doesn’t work for them. And if they do, you won’t know what option is better without a quick test.

However, rapid experimentation doesn’t happen without the right systems and processes at the development, infrastructure, and planning level. Your developers must be unencumbered by technical debt, experiments must be easy to create, and everyone needs autonomy to do this without facing a bunch of red tape or bureaucracy. At its core, rapid experimentation requires the ability to do dozens of releases a day, show some things to some users, and track the results of what’s happening.

Do you want to start rapidly experimenting within your company? Follow these steps to get started:

• Hold a retro with engineering to learn what keeps them from moving faster. Funretrospectives.com has some great options; I recommend anchors and engines as a one-off or the sailboat format for an ongoing view of what’s holding you back.

• Start by setting a realistic goal for the number of tests you’ll create during your next cycle based on your team’s current capabilities. Push the boundaries of what’s been done before.

• Create a list of things you can test. Involve the whole team in a brainstorming session if you like; great ideas can come from anywhere.

• Get started!

I’m going through this process at my company right now. For an early stage startup we move pretty slow, but shifting culture is hard. To get more updates on that journey and other helpful Product Management perspectives, be sure to subscribe to this newsletter.

Subscribe now

If you’re looking for more guidance on how to operate as a product manager within your company and it’s unique challenges, I still have some coaching slots available through Mentorcruise for next year. You get an introductory call for free, and I have various coaching options available.

Share

Lately, though, I’ve had less time to read. Thankfully, audiobooks have helped me keep up with my “reading” while driving, working outside, and making dinners. I was curious how much listening I’ve done, so I looked at my stats. Since I started a new Amazon Canada account in 2018, I’ve listened to over 16 days (384 hours) worth of audiobooks, about 70 titles. That’s nearly 12 books a year. Not too bad.

Subscribe now

Not all of those books are amazing. There’s something to learn from each of them, but a few stand out as being jam-packed with great advice. I’ve read or listened to some of them more than once! Today, I’ll share with you 5 of my favourites. If I had more time, I’d re-read each of these books every year. I’ve recommended many of these to the product managers I’ve coached over the years.

1. The Mom Test - How to talk to customers & learn if your business is a good idea when everyone is lying to you - Rob Fitzpatrick

   How to get honest feedback, even from your mom. Talking to customers is difficult, and getting honest feedback is even harder. As the interviewer, you must dig through the misinformation and get to the truth. The key is to ask the right questions. Geared toward early-stage founders, this book is a gem for anyone in product seeking feedback. Avoid asking if your idea is good; instead, focus on the customer’s issues, experiences, and workflow. Don’t discuss features and opinions.

2. The Right It - Why So Many Ideas Fail and How to Make Sure Yours Succeed - Alberto Savoia

   How can you know you’re building the right thing? Before you build anything at all, what are some things you can do to confirm your assumptions and strategy? Covering eight different ‘pretotyping’ strategies. Pretotyping is a concept covered in the book that explores ways to test for product market fit potential before you ever build the product, such as the well-known fake door test. Savoia makes the whole list readily available here.

3. The First 90 Days - Proven Strategies for Getting Up to Speed Faster and Smarter - Michael Watkins

   The first 90 days of any role are critical, especially as a PM. This leadership-focused book is an excellent guide for product managers at any level. It’s essential in the early stages to be prepared, accelerate your learning, negotiate early goals, and deliver early wins. I’ve discussed this in my post: Your first 30 days as a product manager, inspired by the book.

4. Blink - The power of thinking without thinking - Malcolm Gladwell

   You know that hunch you get about whether something is a good idea or not? That feeling is rooted in science and backed by knowledge and experience you’ve acquired over the years. A great example in the book is how an art historian can quickly spot an authentic piece from a fake. It’s one thing to have a gut feeling, but it’s important to have the ability to articulate what drove you to that conclusion as well. And Gladwell also digs into how to get to that point in this book.

5. Anything You Want - 40 lessons for a New Kind of Entrepreneur - Derek Sivers

   I’ve read this book more than once. I have the originally published version done through Seth Godin’s ‘Domino Project’; this incredible book is not about product management specifically but an interesting tale of finding product market fit, building a great company that people love to work for, and quitting while you’re ahead.

Bonus Book

1. Brand Like a Rockstar - Lessons from Rock n’ Roll to Make Your Business Rich and Famous - Steve Jones

   Even though it’s not geared to product managers, there are some great lessons for early-stage startup PMs. It’s a great alternative view of creating successful b[r]and positioning, revenue models, logos, and hype for your product.

Some of these books would make great gifts; be sure to add a couple to your wish list and maybe even pick one up for a friend.

What books have inspired you most as a product manager? Share some titles in the comments, others would love to check them out.

Share

Sometimes, we just want to push harder, but that’s not always the answer. It's important to recognize failure and know when to move on.

I didn’t want to admit that my business wasn’t successful; it just wasn’t successful yet. Sometimes, it can be hard to know when you’re failing until taking a step back. The hardest yet is making the decision to move on. In last week’s post, I talked about leaving a company as things went south just before the bottom fell out. In today’s story, I hung on for dear life and wouldn’t let go. In both situations, knowing when to move on was a difficult decision.

How do you know if something is failing?

To answer that question, let’s discuss what failure is and isn’t. Failure doesn’t always mean bankruptcy and a complete shutdown. It doesn’t always mean we scrap it and move on because sometimes we just need to tweak things and pivot. So many great products happened due to some amazing pivots like Slack pivoting from a failed game to their internal messaging tool.

Failure is having a goal and not being able to achieve it. Failure is a gap between intention and result. Slack’s story can be seen as a success (despite their failure), because they still succeeded at launching a successful app, even though it’s not the one they started with.

Lots of things can cause failure, including:

• Poor preparation

• Lack of planning or strategy

• External factors beyond our control

• Insufficient resources

• Current lack of skill

• Poor execution

• Unrealistic expectations

Failure means you must have a difficult conversation with yourself about what’s next—a conversation we often avoid at all costs. The sooner you acknowledge failure, the sooner you can move on.

What to do in the face of failure?

Share

When referring to his work creating the lightbulb as we know it (before LED and fluorescent bulbs took over). Thomas Edison is famously quoted as saying, "I have not failed. I've just found 10,000 ways that won't work.”

As I mention that quote, it’s also worth noting he didn’t do it himself. Thomas Edison had a whole team of researchers behind him, tirelessly working in his lab, helping to make the discovery.

Whether you’re working with a team or solo, you will inevitably fail at something, especially if you have a habit of trying new things (which you should if you’re in product management). So, when you do fail, you have a few options. You can:

• Pivot

  The definition of insanity is doing the same thing and expecting different results. So, if something you’re doing is not working, try pivoting it into something else.

• Sell, merge, close, or leave

  This is the nuclear option, but sometimes a necessary one. You can take this option in part or in whole. Don’t shut down the whole thing if you don’t have to; shut down the part that’s not working. Or, leave and admit defeat, take your learnings, and apply them to the next opportunity. It doesn’t mean you’re finished.

• Pause or scale down

  Sometimes, we fail at something because we’re trying to do too much. Reducing scope and focusing on core metrics or features can give us a better chance at success. We can’t be successful at everything.

• Adjust expectations

  Adjust your expectations or that of the business. Accept that your original goals may have been too lofty, and use the new information you have acquired from your first attempts to re-adjust your expectations.

• Try again

  We rarely succeed the first time we try something new. It can take 100s of tries, so learn to admit failure quickly and try again. As product managers, this is the way.

Regardless of the scale of failure, it’s best to think of these scenarios as learnings and pivot or move on from them. In product, we fail all the time; we take what we learn from those failures and apply it to the next thing. At times, we abandon the project or feature altogether, but often, all we need is a slight adjustment in implementation or go-to-market strategy.

A couple of years ago, I said my goodbyes and closed my laptop for what would be my last time working as a Head of Product at a Toronto-based tech startup. I had worked there just shy of two years, and for a few reasons, it was time to move on and experience something new. What I didn't know was that nearly everyone else would be given layoff notices the next day. In the future, that made talking about that part of my job history with potential employers challenging.

Even if you weren't in a leadership role, being part of a cancelled product, project, or company can be a massive blow to your confidence. There are always things we could have done better, and it's not a great feeling to see something you put so much energy into not achieve its full potential. In the story above, we had struggled to meet our goals for a while, but even though the company closed and the software was shutting down, it was still possible to find success stories in my work.

It's not a great feeling when something fails, but products, projects, companies, and features fail every day; it's not that unusual.

There may be things you could have done better or differently, but there are also plenty of things outside your control that can stop you in your tracks, some of these could be considered 'black swan' events. Even very experienced product managers would struggle under these circumstances. It's important to identify things outside your control and not take them too personally. Things like:

• Market shifts: Trends in consumer behaviour, preferences or beliefs that could make your product obsolete.

• An economic downturn or recession: This happens about every 7 to 10 years, so you might be able to predict it in the future.

• Technological advancements: A leap forward in technology could make you obsolete.

• Competitor innovation: A larger incumbent could outpace you by doing something better.

• Natural disaster or crisis: I'm sure you can recall many recent examples.

• Unexpected health issues: Your own or that of key players in your business.

• Supply chain disruptions, Which could co-exist with many of these issues, could make operating your business difficult.

• Regulatory and legal changes: New laws, policies, or compliance requirements could suddenly make your product illegal, harder to sell, or more expensive/less lucrative.

• Media or PR issues: A product or industry issue that gets a lot of media attention could negatively impact you.

Acknowledge the failure, but focus on the successes

When interviewing, you have to showcase your success stories. This is difficult when there's a line in your job history dedicated to a company or product that no longer exists. We really have to dig into that experience and focus on the wins we had while we were there.

So, focus on what you accomplished. Maybe you missed your growth targets, but you were able to really improve user activation or repeat rate. Or, perhaps you implemented a new efficient automated QA process and reduced deployment times from weeks to hours.

Some examples of my past failures:

• Despite getting laid off at one company before I could complete the project I was hired for, I improved internal ticketing by leveraging AI and automation to summarize and categorize tickets. This reduced response times from days to hours.

• At another startup, we failed to close our next fundraising round; our growth numbers weren't great for the last 6 months, but I built an amazing team and an incredible design and development practice and was still able to achieve incredible YoY user growth while lowering customer acquisition costs. (Sometimes, you need to adjust the timeline and zoom out a bit)

Often, we can learn more from our past failures than successes. There is plenty outside of your control, but what can you do better next time? What did you do right? Acknowledge your past failures, but also take note of what you did well and what you could do differently. This isn't the end of the road, and there are still great things you've accomplished, you just might need to change your perspective a bit.

Subscribe now

Share

Over the years, I’ve talked with teachers, mathematicians, scientists, marketers, engineers and designers who have all transitioned to product management. It can be a challenging transition in the best of times, is it even possible now? Of course it is.

Subscribe now

Current economic issues aside, the answer to the question, “Should you become a product manager in 2025?” lies in the answer to “Why did you want the job in the first place?” It’s a lot of work, so it helps to really want it.

These may not all apply, but here are a few reminders:

• Impact

  It’s likely that in your previous roles, you’ve wanted to have more impact. It might be impact at scale, across a team or multiple teams, or a greater impact by making better decisions than your predecessors.

• A little bit of everything

  You like working with data, customers, designers, and engineers. Maybe not all of those things, but you no longer enjoy staying in your lane, that’s for sure. You prefer to wear many hats, adding your touch to everything.

• Big picture

  You can’t help but think about the bigger picture. In your previous roles, you asked about impact and wanted to understand better what led to the decisions that resulted in the next new thing.

• Strategy

  You weren’t content with just building the next great thing; you always wanted to help decide what the next great thing would be. You may have sat in on planning or strategy meetings, hoping to have your voice heard.

• Hard work

  You’re willing to work hard and understand that not all worthwhile things come quickly.

• Customer advocacy

  You may feel connected to the mission or empathize with your customers' daily struggles. When you hear, ‘voice of the customer’, you picture yourself.

• Tough decisions

  You’re good at making hard decisions. You leverage data and consider the impact your decisions have on others. You’re not afraid to make the tough calls and admit when you were wrong.

• Experimentation

  You’re a tinkerer and like to experiment with new ideas. You might have side projects, are always looking to improve processes, and like to try new things.

• Lifelong learner

  To succeed in your career in product management, it’s helpful to be a great learner. You have to be an expert in many different areas, and the world around you is constantly changing. It’s essential to keep up with the times.

• Process driven

  You’ve implemented processes in your previous roles, and wish you could do so at scale across the whole product org.

So, which values do you align with? Did I miss any?

2025 may not be the greatest year for anyone in tech, not just product managers. If you’re looking to transition to product management and are currently in between roles, it might be an excellent way to expand your options.

If you’re already in product management, it may make sense to double down. Unless you were very recently an engineer, designer, or analyst, going back to your previous roots may be more of a struggle than pushing forward with your current career. Some alternative job titles you might want to consider if you’re open to a slight pivot but still want to stay within the realm of product management: Marketing Manager, Strategic Director, Chief of Staff, Growth Marketer, or Product Operations Manager.

Anything is possible; I’ve made several career changes myself, from Photographer → Engineer → Designer → DevOps/Engineer → Product Manager.

If you want help navigating the current hiring environment (I’ve recently been through this myself, see my post on my recent job search), or you need help dealing with the struggles of product management, I offer ongoing coaching options, and am available for one-off calls.

Share

Maybe I’m getting old and nostalgic, but others are saying the same thing.

The new Starbucks CEO, Brian Niccol, recently said that the company is returning to its core identity, simplifying the menu by removing drink options and focusing on what they were once known for: self-serve condiments and names written on cups. And guess what? This simplification will drive prices down.

As product managers, we can apply this thinking to our own products. We’re great at building new functionality and adding complexity, but we’re generally bad at removing things that aren’t working. As a result, our products become bloated, and our companies lose sight of the problem we were initially trying to solve.

This is a systemic problem that we can at least partially blame on the need for continuous and endless growth. To grow, you must increase market share. That means expanding into new customer markets. This requires new functionality, more complexity, and massive scale. This added cost perpetuates the need for even more growth, and the cycle continues.

I can’t prove it, but I think there’s a place for more companies that sell Seattle’s best coffee (in Seattle only) or donut shops that don’t also sell pizza.

Subscribe now

I remember the original Tim Horton’s. In the 90s up until the early 2000s, they were actually good. They sold coffee, donuts and bagels, but that was it. Now they sell pizza! Their donuts and coffee are terrible, and everything is more expensive. What happened? Still to this day, 50% of their sales are in the morning, and of that, 60% is coffee. As with most things, the 80/20 rule applies here.

Too many companies are focused on expanding their capabilities to the detriment of getting the core things right. Complicated products are everywhere and end up being confusing for your company, as well as your users. They lead to a lack of focus and are difficult to manage. They add complexity to the company and organizational structure, they have future maintenance costs, and your core offering suffers.

Are you a CEO looking to expand your company offering, jump into a few M&As, or add gamification to your app? Go back to basics instead and perfect the essentials of your business and product. You wouldn’t add a second story to your house if you weren’t sure you had a solid foundation. And even if you think you have a solid core offering, remember, all of that additional stuff comes with huge costs, both financially and in terms of where your attention is going.

I’m calling it now. Over the next decade, we’re headed into an era where the companies that succeed will be those focused on doing one thing and doing it well.