1. The Outcome by ProdPad
2. Lenny’s Newsletter by Lenny Rachitsky
3. Product Practice by Tim Herbig
4. Morning Brew
5. Product Talk by Teresa Torres
6. Prioritised by Mind the Product
7. ONE THING by Bruce McCarthy
8. SVPG Newsletter by Marty Cagan
9. The Looking Glass by Julie Zhuo
10. Reforge
11. The Product Vibe by John Mansour
12. The Beautiful Mess by John Cutler
13. Growth Unhinged by Kyle Poyar
14. Work in Progress by Rick Pastoor
15. UX Collective newsletter
16. Product Managers at Work by Alexis Hebin Kim and Adrienne Tran

1. The Outcome

The Outcome is our very own newsletter here at ProdPad. There may be a minor, very small chance that we’re a little biased, but we think it’s pretty great. It’s a treasure trove of insights for Product Managers from raw newbies looking to learn, to old hands wanting to keep up with the latest thought leadership and best practice.

In each edition, you can expect articles on topics like user research, customer feedback, feature prioritization, and product metrics, as well as useful product management resources like this list! The Outcome also often includes info about our upcoming webinars featuring industry experts, giving you access to the latest thinking and best practices in the field.

It covers the entire product management lifecycle, from idea conception to product launch, and beyond. Whether you’re a novice or a seasoned pro, The Outcome ensures you stay up-to-date with the ever-evolving world of product management. It’ll also let you know about the latest and greatest updates we’ve made to our own product, to highlight how we’re making your work day easier with every release.

2. Lenny’s Newsletter

Lenny Rachitsky, a former Airbnb product lead, has created a newsletter that has gained something of a following in the product management community. Lenny’s Newsletter is a rich source of deep insights into product strategy, growth tactics, and the art of building exceptional products. 

Lenny leverages his extensive experience to provide subscribers with data-driven analyses and practical takeaways, with regular updates multiple times a week. He also hosts an entertaining and informative podcast series, unsurprisingly titled Lenny’s Podcast.

Expect to find comprehensive case studies and in-depth explorations of successful product launches in this newsletter. Whether it’s dissecting the strategies of tech giants or uncovering the secrets of startups, Lenny leaves no stone unturned. Lenny’s Newsletter is an indispensable resource if you’re seeking a newsletter that combines real-world examples with strategic thinking.

3. Product Practice newsletter

Tim Herbig’s Product Practice newsletter is a must-read if you’re looking to get your hands dirty digging into the intricacies of product management methodologies. Tim, a highly seasoned and well-respected Product Manager, distills his knowledge into easily digestible insights. Each edition offers practical advice, templates, and frameworks that can be immediately applied to your product management workflow.

Tim often explores product discovery, roadmapping, and effective communication within product teams. He also shares valuable resources, books, and tools that have been instrumental in his own career. He wants to challenge how you approach your product, to help you find your own approach.

His articles are really good reads, and you’ll come away from them knowing something you’ll be able to start using straight away. If you’re seeking a newsletter that bridges the gap between theory and practice, Product Practice is a valuable resource for honing your product management skills.

4. Morning Brew

While not exclusively focused on product management, Morning Brew is a widely recognized and respected source of business, tech, and finance news. Its unique blend of informative content, wit, puzzles, and brevity makes it a favorite among professionals across various industries, including product management.

In each daily edition, the Morning Brew delivers a concise and engaging summary of the day’s top news stories, including those related to technology, startups, and innovation. As a Product Manager, staying informed about broader industry trends and economic developments is crucial. Morning Brew provides this wider context, helping you make informed decisions in your role.

Another bonus is that Morning Brew often features special reports and deep dives into specific industries, offering valuable insights that can inform your product strategies. 

5. Product Talk

Product Talk is a newsletter curated by the fantastic Teresa Torres, and it goes beyond just surface-level discussions of product management. Teresa, a product discovery coach with years of experience, offers a deep dive into product strategy, design, and innovation. Her newsletter is designed to help Product Managers make better decisions by providing them with the tools and insights they need.

One of the standout features of Product Talk is the focus on user research, emphasizing continuous discovery and customer-centric product development. Teresa often shares techniques, case studies, and real-world examples of how to conduct effective user research and translate those insights into product improvements. If you’re looking to refine your product discovery and development processes, Product Talk will set you on the right path.

It’s not just practical advice though. Product Talk often includes thought-provoking essays and commentary on the state of the product management industry. Teresa’s unique perspective and expertise make this newsletter a must-read for anyone looking to deepen their understanding of product management principles.

6. Prioritised

Prioritised is the newsletter from Mind the Product, a community of Product Managers and product enthusiasts (that I am a co-founder of!). Mind the Product is renowned for their conferences and events, and their newsletter is an extension of their commitment to product excellence.

In each edition, Prioritised brings together insights from a diverse range of product experts and thought leaders. It covers a wide array of topics, including product leadership, design thinking, and innovation. It provides fresh and varied perspectives on common product management challenges.

Mind the Product also often features updates on their events, workshops, and webinars, as well as product job listings, making it a valuable resource for networking and professional development.

7. ONE THING

Bruce McCarthy’s newsletter, ONE THING, is a concise and thought-provoking resource for Product Managers. As a co-author of “Product Roadmaps Relaunched,” Bruce has a wealth of experience in product development, and he distills his wisdom into bite-sized, actionable insights in each newsletter. 

In Bruce’s own words, in each weekly offering, you can expect to find: “One insight I had, one great article I read, one amazing person I met, one question I need your help with, one product job that needs someone awesome”

ONE THING focuses on the fundamental aspects of product management and product culture. You’ll get articles on topics like prioritization, roadmapping, and fostering a culture of innovation. What sets this newsletter apart is its commitment to delivering one key idea or concept in each edition, allowing readers to absorb valuable knowledge quickly.

Bruce’s approach to product management emphasizes simplicity and clarity, making ONE THING an easy win if you like your advice straightforward and actionable. If you’re looking for a concise yet impactful newsletter that hones in on the essentials of product management, ONE THING is a great choice.

8. SVPG Newsletter

The SVPG Newsletter is brought to you by industry legend Marty Cagan’s Silicon Valley Product Group, a well-respected consultancy known for helping organizations build successful products. This newsletter is an extension of SVPG’s expertise and offers valuable insights and strategies for Product Managers.

In each edition, you’ll find articles and resources covering a wide range of product-related topics, from product leadership and innovation to user experience and product-market fit. The SVPG team leverages its extensive industry experience to provide practical advice that can help you excel in your product management role.

One of the best things about this product management newsletter is its emphasis on product leadership and team dynamics. Marty or his partner Jon Moore often pen articles exploring the challenges of leading product teams effectively, making it a source of knowledge for aspiring and seasoned product leaders alike.

9. The Looking Glass

The Looking Glass is a unique and thought-provoking newsletter that offers a fresh perspective on product management. Authored by Julie Zhuo, co-founder of Sundial and former VP of Product Design at Facebook, this newsletter is a series of essays and musings that contemplate the future of product management and design, innovation, and how to effectively lead a product team.

While not as practical as some of the other newsletters on this list, The Looking Glass excels at sparking critical thinking and encouraging readers to consider the bigger picture. It’s a great jumping-off point for Product Managers who want to challenge their assumptions and explore new ideas. However, it’s worth noting that half of the newsletter is restricted by a paywall.

Expect to find content every other week that explores the intersections of technology, culture, and human behavior. The Looking Glass is an intellectual exploration of the product management landscape, making it a compelling read.

10. Reforge

The Reforge newsletter is an excellent resource for Product Managers and growth professionals looking to advance their careers. It’s not exclusively focused on product management, but even so it offers insights and strategies that can benefit PMs and other product people.

Reforge often features articles, research, and interviews with industry experts that dive deep into topics like user acquisition, retention, and monetization. It’ll give you actionable insights and frameworks that can be applied to optimize your product’s growth and user engagement.

What makes the Reforge product management newsletter shine is its commitment to data-driven decision-making and experimentation. It equips you with the tools and knowledge you need to drive growth and success in today’s competitive landscape.

11. The Product Vibe

The Product Vibe is produced by the Product Management University, and curated by founder John Mansour, and it’s a monthly must-read for product people. John’s been everything from a Pre-Sales Solution Consultant to a Product Marketing Manager and Product Manager, and this wide range of experience means he brings a ton of different perspectives to the table, especially when it comes to understanding how product management impacts other areas.

This isn’t just your typical product management advice, either; it’s best practice tailored to the specific challenges and opportunities you’ll face when working holistically in product. Reading his newsletter is a deep dive into the nuances of B2B and B2B2C, giving you the kind of targeted knowledge that can help set you apart from the competition.

The way John links product management to the overall success of a business is also something that really stands out. He doesn’t just focus on the immediate responsibilities of a Product Manager. Instead, he shows how good product management practices ripple out to positively impact areas like Marketing and Customer Success. It’s about understanding the bigger picture and how your role as a PM fits into that. This broader perspective can be a game-changer, especially when you’re looking to make a significant impact in a larger organization.

12. The Beautiful Mess

The Beautiful Mess from John Cutler is a pretty awesome resource for Product Managers. First off, John’s fascinating insights on product development can really help you if you’re trying to get better at managing projects that involve a bunch of different teams. He’s worked as a Product Evangelist at Amplitude, so he knows his stuff when it comes to creating products that not only rock the market but also play nice with all parts of a company.

His knack for mixing hard data with the softer, more human side of things also brings a rare and valuable take that you don’t often see. This is super important – as a Product Manager, you’ve got to make decisions based on solid facts, but you can’t just ignore what users are saying if it disagrees with your numbers. John’s newsletter is like getting a weekly dose of this balanced perspective, which is great for keeping your skills sharp and your empathy honed.

13. Growth Unhinged

Kyle Poyar’s Growth Unhinged is another real gem. Kyle dives into the nitty-gritty of what it takes to scale products and teams, and his insights come from a pretty solid place – he’s an Operating Partner at OpenView. This means he’s constantly in the mix, checking out what the fastest-growing startups are up to. So, when you’re reading his newsletter, you’re getting a peek into the strategies and tactics that are working in the real world, right now.

Then, there’s the community aspect of his product management newsletter. Kyle’s not just throwing information at you; he’s actually fostering a space where founders, investors, and product folks can share their best advice and growth insights. This kind of community vibe makes the newsletter more than just a read; it’s like being part of a club where everyone’s keen on growing and learning together.

Each issue is packed with case studies and strategies, but it’s also super accessible. Whether you’re a seasoned PM or just starting out, you’re bound to find something that resonates.

14. Work in Progress

Work in Progress by Rick Pastoor, the brain behind the bestseller GRIP – The Art of Working Smart, is like getting a weekly boost for your product management skills, even though it’s not exclusively PM-focused. The great thing about this newsletter is that it’s not just about the dry, technical side of working.

Instead, Rick brings a more human and approachable side to the table, and his insights are all about making your workweek more productive and meaningful. He’s got this knack for hitting just the right note that makes you think, “Ah, that’s something I can really use!”

One of the main draws is how Rick focuses on practical tips that can be applied right away. It’s all about action, not just theory. Each issue is like a mini coaching session, offering you a chance to reflect on how you work and how you could tweak things for the better. It’s the kind of read that can transform your Monday blues into a “let’s do this” attitude, which is pretty rare and valuable.

15. UX Collective newsletter

The UX Collective newsletter is all about giving you a fresh perspective on product design – moving beyond just ticking boxes and genuinely innovating in the design space. It’s like getting a regular dose of inspiration that can totally change how you approach designing your products. The newsletter covers a lot of ground, from user experience tips to the latest design trends, and it’s super helpful for keeping your ideas fresh and your skills sharp.

You don’t need to spend hours sifting through articles and blogs; this newsletter brings the cream of the crop right to your inbox. It’s a time-saver and a life-saver for busy Product Managers who want to stay in the loop without getting overwhelmed.

16. Product Managers at Work

Product Managers At Work by Alexis Hebin Kim and Adrienne Tran is pretty much a goldmine for product managers. Getting insights straight from folks who’ve been in the trenches at big names like Facebook, Tesla, and Google sounds almost too good to be true. Their experiences in these top tech companies are like a treasure trove of best practices and innovative ideas that they’re just handing over to you.

Another cool thing about their newsletter is the variety of topics they cover. It’s not just about launching products; it’s about the whole journey – from dealing with crises to scaling teams and everything in between. This newsletter is a behind-the-scenes tour of the product management world, giving you a glimpse into the minds of people who’ve successfully navigated big challenges. It’s a fantastic way to learn how to handle the kind of situations that keep PMs up at night.

The personal touch that Alexis and Adrienne add to their newsletter makes it really stand out. It’s not just by-the-book advice; it’s real stories from their own experiences. This approach makes the lessons more relatable and digestible. You’re not just reading tips; you’re learning from someone else’s journey, which can be incredibly powerful and inspiring.

Why reading product management newsletters will make you a better PM

Product management isn’t just a job. It’s a dynamic and constantly evolving discipline, and it requires a commitment to continuous learning and adaptation. That’s why you need to be inhaling product management newsletters – they’re invaluable assets for product professionals who really want to excel in their roles. 

When you keep that in mind, where else are you going to get insights from the brightest minds and thought leaders in the product world than straight from the horse’s mouth?

Here’s why you should make a habit of reading product management newsletters in 2024 and beyond:

1. Stay informed and relevant: The product management landscape is notorious for its rapid changes in technology, market dynamics, and user expectations. Subscribing to newsletters keeps you informed about the latest industry trends, emerging technologies, and shifts in consumer behavior, helping you to ensure your product strategies remain relevant and adaptable.
   
2. Access to expert insights: Many product management newsletters are curated by industry experts, thought leaders, and seasoned practitioners. These individuals possess a wealth of experience and knowledge, and their newsletters offer direct access to their insights and wisdom. Learning from the experiences, successes, and failures of these experts can help you avoid common pitfalls and make informed decisions.
   
3. Continuous learning: Successful Product Managers are lifelong learners. Newsletters provide a structured and time-efficient way to consume new information, research, case studies, and best practices. They offer bite-sized, easily digestible content that you can integrate into your daily work, ensuring that you’re constantly growing as a professional.
   
4. Networking opportunities: Product management newsletters often include announcements and information about industry events, conferences, webinars, and meetups. Attending these events can be an excellent way to expand your professional network, connect with peers facing similar challenges, and exchange ideas with fellow Product Managers.
   
5. Career advancement: Staying updated through newsletters not only enhances your skills but also opens up career advancement opportunities. Knowledgeable and proactive Product Managers are highly sought after in the job market. Subscribing to newsletters can help you identify new roles, job openings, and companies aligned with your career goals.
   
6. Fresh ideas and innovation: Newsletters frequently feature case studies, innovative product launches, and creative solutions to complex problems. By keeping up with these insights, you can inject fresh ideas and innovative thinking into your product development process, leading to more successful outcomes.
   
7. Time efficiency: Scouring the internet for relevant articles, blog posts, and research can be time-consuming. Newsletters streamline this process by delivering curated content directly to your inbox, saving you precious time that you can allocate to strategic planning and execution.
   
8. Community building: Many product management newsletters foster a sense of community among subscribers. Engaging with these communities can lead to collaborative opportunities, mentorship, and a sense of belonging in the broader product management profession.

Whether you’re a seasoned Product Manager or just getting your feet wet, if you’re seeking practical tips, strategic insights, or a fresh perspective on the industry, subscribing to these product management newsletters in 2024 will keep you well-informed, inspired, and equipped for excellence in your product management journey.

The post The 16 Best Product Management Newsletters in 2024 appeared first on ProdPad.

What does a good product roadmap look like?

The litmus test for a good product roadmap template to start from is that it’s visual, accessible, and clear. Anyone should be able to scan it and find answers to the following questions:

• What are we doing?
• Why are we doing it?
• How does this tie back to our OKRs?

This is the fundamental idea behind a theme-based product roadmap – and its benefits are enormous and immediate. It will help you be able to:

• Have way fewer meetings – Your priorities (what and why) are clearly documented on the roadmap. You don’t have to explain things differently to different people.
• Foster healthy team debates – Your roadmap can be the reference point team members use to challenge themselves and one another to link their deliverables back to roadmap goals and OKRs.
• Make product decisions everyone understands – You’re no longer the bad guy batting down ideas. You can actually discuss customer feedback and ideas through the lens of your roadmap and priorities everyone can see.

In the words of product discovery coach Teresa Torres:

“We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd. Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions.”

A theme-based roadmap is designed to do just that: communicate problems to be solved and open up the conversation around how to solve them. 

If you want to dig into this more, I recommend checking out our CEO Janna Bastow’s excellent presentation on using your product roadmap as a communication tool.

Start with this theme-based product roadmap template

You’re probably already familiar with feature roadmaps – they usually look like Gantt charts or release plans. These are useful for planning projects, but they don’t communicate the big picture very well.

Our theme-based roadmap of choice, the Now-Next-Later roadmap, replaces that with time horizons, made up of three columns:

1. Now: Stuff that you are currently working on.
2. Next: Stuff that’s coming up soon.
3. Later: Stuff that you’d like to work on in the future, but need to do a bit more research before you move on.

Note that we aren’t showing any timelines. This is not a release planner, it is a bird’s-eye view of your priorities. Those are always subject to change – there’ll always be something that happens in the future that you can’t meaningfully plan for today.

The point is to leave room to adjust to change. If something you’re working on was current but now you want to push it back, you can.

Define Initiatives for your roadmap

Themes are “a promise to solve problems, not build features,” says Jared Spool, founder of User Interface Engineering.

The idea behind Initiatives is that it’s better to tackle the root of the problem with a single, elegant solution than burden yourself with a growing laundry list of features. You should be working at the problem level, asking what you can do to solve specific issues, rather than plotting out what feature to build next, just for the sake of having a feature to build next.

Developing initiatives for your theme-based roadmap enables you to define priorities in terms of problem areas, which are things that everyone can understand. It also enables you to actively incorporate the daily flow of customer feedback into your product planning.

For example, if you’re getting a lot of feedback for Single Sign On, then now’s not the time to drop everything and build 10 new ways to sign into your app. Rather, it’s time to set up a new roadmap card (like the ones you see below) and start pulling all this feedback together to help you explore the best way to start solving this problem (Fun fact: ProdPad’s AI assistant can help do this for you!).

This enables you to communicate with your company that you’re aware of the problem and that you’re thinking about it, but you don’t have to provide anyone with the exact solution at this stage.

Each of the following roadmap cards represents an initiative except the last one.

Why has the last one been crossed out? Because roadmap cards should always be strategic, not tactical. “Rewriting transactional emails” is too specific to be a strategy. It’s a task rather than an initiative.

At this high-level view, those are details you don’t have to worry about yet. Save the granularity for when you get into the details of each card.

Build the case for each Initiative

Once you have your Initiatives down, you can attach more supporting details for anyone who wants to drill further down. These details help us strengthen what we’re putting on our roadmap, which again, could include useful information for those reading it:

• What are we doing?
• Why are we doing it?
• How does this tie back to our OKRs?

Internally, your team will have access to detailed information which will help prepare them and guide them through your workflow. These details include:

• Ideas – Tactical suggestions for improvement. These ideas answer a simple business case: What problem are you trying to solve?
• Customer feedback – We attach feedback directly to ideas in ProdPad, so they can be linked to potential improvements and we can easily track what our clients are asking for.
• User stories – Use case scenarios for ideas: As a user, I want to X in order to Y.

Cards sitting in the Later column don’t have to have all those answers yet, but as a card moves closer to the Now horizon, they should become a lot more detailed.

Assemble Initiatives into a product strategy

As you build your theme-based roadmap, you can color code and tag them to allow the viewer to sort through and filter down based on a particular interest. Kind of like you do with Post-it notes!

How about that basic usability, huh? This keeps it visually easy and engaging, and everyone will be happy you didn’t make them sort through herds of cards to find what they came for.

Instead of staring blankly at one big roadmap, your colleagues can focus on the ones that are relevant to them.

Now tie it all together with ‘The Guide to Roadmapping’

Cool, nice roadmap! But what do you do with it? Our CEO, Janna Bastow, gave the most comprehensive talk out there about how you can introduce your new product roadmap template across your business. It’s just 20 minutes – a perfect companion to the flexible roadmapping method you’ve just learned.

We’ve also crafted a free course which takes you through all the steps to move your organization from a timeline roadmapping approach to a Now-Next-Later theme-based roadmap.

And to really get the job done, we’ve even created a ready-made presentation deck that you can download and present to your stakeholders to convince them that moving to a theme-based approach is better for business!

Start building your new theme-based roadmap in ProdPad

Hit the button below to start your free trial today! Discover how to build a product roadmap in a tool that’s designed by product managers, for product managers.

Start your free trial

Enjoyed this article? Check out our product management blog for more key insights.

The post Theme-Based Product Roadmaps: Something Everyone Can Understand appeared first on ProdPad.

We’re sharing it with you because it’s a productive way to work out priorities as a team, and it’s a really helpful method for mapping development. Who said product management couldn’t be fun?

One of your biggest jobs as a product manager is to translate and prioritize what feels like a million inputs flying in from across the company into just one cohesive product roadmap. To help you with this, we want to share one of our favorite feature prioritization frameworks with you. 

During this game, everyone gets a chance to bring up the priorities they feel are important for the future of the product. But which priorities will win?

You’ll want to set aside an entire morning or afternoon for this riveting afternoon of discussion, debate, and feature prioritization.

The more people you involve in the process, the better the understanding will be across the board. A good mix of internal stakeholders and active users will provide you with more valuable insights than just getting your product teams together in isolation.

Below you’ll find our easy how-to guide on running your own Product Tree session using this fun visual tool. We’ve also got a brilliant eBook about all of the most important prioritization frameworks for product managers. Just click the banner below to get your copy.

How to run your Product Tree Game session 

What you’ll need:

1. The Product Tree template (download below)
2. Post-it notes (leaf-shaped Post-its are perfect)
3. Sharpies 
4. A whole afternoon 
5. Coffee? Can’t hurt!

Step 1: Print our Product Tree template 

The Product Tree is what you’ll use to run your session. Get our free Product Tree template here, or draw your own out on a big whiteboard.

Each Product Tree consists of four elements:

• The trunk represents the core features already in your products.
• The branches are feature branches. Optionally, you can increase the thickness of single branches that are more important.
• The leaves are individual features that the workshop participants will place on the branches. The closer the leaves are to the trunk, the closer they are to being delivered.
• The roots represent the infrastructure and technical requirements that support your product. As with any tree, the bigger it gets, the more support it needs from its roots – so remember your technology as you expand your feature list.

That said, how you fill out this tree depends on the kind of product you want to build. If you want to focus on one area, your product could be the roots, and the area you’re focusing on would be the trunk.

Or, if you’re running a platform with multiple products, the platform itself could be the trunk, and the main branches would represent each of your products. 

Whatever the scale of your approach, you’ll need to list out the main areas of your product and label the branches of your tree accordingly. If your product areas have chunky bits of functionality or features within them, you could add those to the stubs of the branches. 

Step 2: Prepare your leaves  

Print out all the features you already have in your product, or want to add to your product. Or, write them down on Post-it notes. Also, make sure to have plenty of empty Post-its at hand for adding new ideas!

Don’t worry about adding all your existing features, because if you have a feature-rich product, you’ll be there all day.

Step 3: Get your group together  

Anyone can play this game. The more kinds of stakeholders you involve, the richer the output. It becomes especially interesting if you get customers involved in placing new features on the branches according to which they would most like to see in your product.

If you have more than 10 people joining in, prepare multiple sets of trees and leaves – ideally, you will have 4-10 people working on one single tree. This includes one observer per tree, whose role it is to ask the participants to clarify what they mean if there’s anything ambiguous on the tree. 

Step 4: Put the leaves on the tree 

Ask everyone to write their feature ideas on the (hopefully) leaf-shaped Post-it notes, then get them to place the Post-its onto the tree wherever they think they should go.

The further away from the trunk they are, the more into the future you’re planning. Leaves closer to the trunk are closer to deployment, while the canopy of the tree is more about long-term growth. 

Step 5: Prune your Product Tree 

Now the fun begins – like green-thumbed gardeners, get cracking on pruning the tree!

Pruning in this case doesn’t always mean outright cutting things from your tree, though. Really, ‘pruning the Product Tree’ is more about assessing what you put on your tree, and then collaboratively reorganizing it.

Moving features around or adjusting the thickness of a branch is just as valid as cutting an impractical idea (though you’ll still want to do that – but make sure hang on to them for the review phase). 

Together as a team, you’ll need to talk through the placement of each leaf, and work on refining where they sit on the tree as a whole. This means that you need to identify and remove branches, leaves, or even roots that are hindering long-term growth or putting roadblocks in the path of your solutions.

Once your team has put together their tree, they need to assess each leaf’s importance. How much value does it adds for your customers? How does it align with your product vision? And how much effort it would take to implement or to maintain? These are some of the questions you’ll want to throw out about each idea.

Consider the importance and impact to the customer, the relevance to your product vision, the effort required to bring it to market, and the impact on your business goals and product strategy.

Tips for having a successful Product Tree workshop

Here are some pointers on how to have a productive and fun Product Tree pruning session: 

• Personalize the tree to stimulate creativity. For instance, participants can add their own little markers to their ideas, or draw hearts around the features they really love. 
• Remember the significance of where leaves are placed. The closer the leaves are to the trunk, the more near-term they are. Leaves closest to the trunk are existing features, while leaves on the outer edges of your canopy represent the long-term future. 
• Don’t hesitate to use lines to show links or dependencies between features. Though try not to end up looking like Charlie in It’s Always Sunny.
• Don’t worry too much if the tree becomes unbalanced. Usually, the group participants or the observer will bring this up naturally. 
• Take pictures of the development of the tree(s) – this is useful for the review process. 

Step 6: Present and review internally 

At the end of the session, present your tree (or multiple trees if you worked in groups). Encourage everyone to ask questions and discuss. Often, more ideas will come up during this process, or leaves will be shuffled around.

Once you’re all packed up, take your product tree and the pictures you took and compare them against your current product roadmap. Useful questions to ask are: 

• Which “prepared features” got pruned? Especially if you’re working directly with customers, you might find that a much-loved feature is actually dispensable in the eyes of the user. 
• Do the trees retain their general shape? If you’re seeing an obvious imbalance – such as lots of leaves on one branch – this could be a signal that your users aren’t aware of (perception problem) or interested in (product/market fit problem) a whole feature set in your product. 
• Are you growing your product fast enough? If there are a lot of leaves close to the trunk, you may not be releasing new features fast enough; whereas lots of leaves on the outside shows that they’re looking for great things in the future. 
• What does your root system need to look like? If your customers are changing aspects of your infrastructure, it’s likely of critical significance to them to establish trust in the longevity of your product. 

At ProdPad we find the Product Tree game is a great way to dig into feature prioritization. Don’t forget to check out our free prioritization framework eBook, and if you need even more detail on the best way to run a Product Tree session, take a look at our free manual here. They’re both fantastic resources to help you with creating your lean product roadmap.

The post The Product Tree Game: Our Favorite Way To Prioritize Features appeared first on ProdPad.

This is a valid question, and the short answer is that experience is best gained by doing. You can try your hand at all kinds of product work, no matter what your current job title.

It’s true! There’s so much solid PM-like experience to be gained through independent activities, such as side projects and showing up to product management events, plus just listening to and learning from other people in the field.

Whether you’re already at a tech company or not, you can find a way to hone that PM instinct, showcase product skills, and present a portfolio of work at your next interview.

We’ll walk through each of these, but first, what is that PM instinct anyway?

As product managers, we don’t necessarily follow the data, and we’re not driven by pure numbers. We often have to follow our guts.

But this “gut feeling” is not woo-woo at all, it’s learned pattern recognition. Great product managers have developed a strong instinct based on the accumulation of so many different, tiny experiences that we’ve collected over the years. The more experiences that PMs absorb, the better product people they’ll be.

So, the question comes back to: How can you accumulate more of these experiences? How can you prove you’re developing a PM instinct, when you’re not yet in the role?

Now we’re ready to dig in.

4 ways to get Product Manager skills

1. Do your own side projects

Side projects will build up your portfolio, and show that you can understand and break down a problem. This is one of the most important ways to prepare for a PM interview.

In your spare time, take up some sort of hobby or project that allows you to tackle a small problem.

Examples of side projects you can try:

• No or low-code apps
• Household chore app for roommates or shared living
• Hobby tracking app
• An app that alerts you to a routine: When to water your plants? When to order the next coffee delivery? When to call your parents?

It doesn’t need to be a world-changing problem. It doesn’t have to be complicated. The key is to really think about it from a product manager point of view.

So, really think about it! Not in terms of the solution you want to build, but about what kind of problems are out there. Ask actual people, create a Typeform to get ideas or feedback. (You’ll have to do this as a PM anyway!)

Ultimately, your side project should do the following:

• Show that you’ve done some research.
• Show that you’ve understood a problem and how users work.
• Give you an opportunity to explain how you broke down the problem and reached your solution. Why did you make that thing? How did you get there? 

In fact, what your side projects don’t have to do is function seamlessly or even solve the problem you set out to fix!

Your portfolio can include failures

If you’ve dabbled in projects and some have failed, that’s fine! That’s normal. Honestly, a bunch of them are going to be crap products that don’t work.

We can learn a lot through failure. The process is more important than the outcome.

As long as you can demonstrate your process, as well as what you’ve learned about the problem and why it’s hard to solve, that’s valuable. It gives you interesting insights that you can then take to an interview situation and into an actual PM role.

2. Working product-adjacent: Simulate a Product Manager

If you’re currently working in a product-adjacent team, such as support, sales, or marketing, you should have plenty of opportunity to gain PM experience in your current role.

Of course, you can ask to shadow the product team. But you likely already see some problems your customers are having (or that the product team is trying to solve), and you could start exploring these on your own.

This is how I got noticed as a potential PM and got my first leg on the product career ladder.

Now, I’m not saying you should go build a solution or step on your current product manager’s toes, just start thinking about how you’d break down the problem. Write down ways that you would look at solving it. And by “write down ways,” I mean literally pull out a bunch of Post-It notes and map out some flows.

This is what product managers do. And here’s what you can do in your current role:

• Spot problems and document them like a PM would
• Come up with ideas about how to conduct research
• Hypothesize and present potential solutions

You can take this to your internal product team, or even externally to an interview, and present it as product-type work that you’ve endeavored on your own.

3. Not product-adjacent: Join a support or success team

If you aren’t currently at a company where you work adjacent to a product team, you might have more questions about how to become a PM. One excellent entry point to the field is to begin in customer support or customer success.

By working in customer support or success, you gain all kinds of experience in talking to customers, troubleshooting issues, identifying problems, and – of course – learning a particular product inside and out. All of this can be easily parlayed into a product role!

In fact, I started out as a customer support rep. The IT team noticed that I was really good at talking to the customers and to the devs. My next role was as junior product manager.

That said, great product managers come from anywhere. You don’t need customer or tech experience to land a PM job or do well. I know former lawyers and real estate agents who are now successful PMs.

There’s no given path or set of paths. You just have to be able to ask the right questions.

4. Learn from other product people

The next best thing to first-hand experience is learning from others, hearing their stories so you can spot the patterns and apply them to your own situation. Believe me, you still learn a lot if somebody else tells you about how they tried something and it blew up in their face.

I didn’t know other product people until a few years into my product career. Thanks to Mind the Product, I’ve listened to hundreds or even thousands of product talks at this point.

Learning from other PMs is like an accelerator; it speeds up your development without you needing to go through every experience yourself. Product Management isn’t a hard skill, you don’t need a tangible apprenticeship. It’s mostly communication skills! You’re listening to people, you’re talking to your team and customers and trying to understand them.

So, by listening to and absorbing what other PMs have to say, you multiply your own experience and product manager skills.

Learn from product folks in the following ways:

I hope that gives you some inspiration for pursuing a new role in product or amping up your career. You can gain the right experience in many different ways.

Bottom line

Don’t ever let the fact that you’re not (yet) a product manager stop you from doing product management work.

The post Product Manager Skills: The Best Way to Gain Experience? appeared first on ProdPad.

To find the source of these misaligned incentives, so you can start understanding and doing something about them, you’ve first got to understand the root of the problem.

The Iron Triangle of constraints – the root of the incentives problem

You might be familiar with the Iron Triangle of time, cost, scope, and quality. For any one of these factors to give, we’ve got to be willing to give on another front. 

We rarely have the spare budget or all the time in the world to play with, so time or cost is often flexed, in exchange for scope and quality. 

This is exactly what we’re doing when we run experiments using quick prototypes and MVPs—we’re trading off our requirement for perfect quality or 100% full scope in order to gain back a chunk of valuable time and cost.

Those time and cost-saving are hugely valuable to any company looking to move quickly and iterate what it learns from experimentation.

As product people, we make these trade-offs all the time, often without even realizing it. These trade-off decisions help us achieve the best balance of speed and quality of output needed to achieve the outcomes we are aiming for.

The problem comes when different stakeholders in the business are incentivized to see different outcomes and yet are still bound by the constraints of the Iron Triangle.

Misaligned incentives spell trouble for product teams

One of the most common sources of tension in a team is a situation just like this: A person in your tech team and a person in your sales team are in a disagreement about something that you’re trying to deliver. It’s not a personal thing. They’ve just got different ideas of what the outcome should be for the initiative and bending their will to the other means going against what they’re incentivized to do.

More often than not, it’s your developer who’s advocating for the quality and scope side of the equation. They want it done fully and done right. The salesperson wants it out the door sooner rather than later and is annoyed they aren’t getting clarity on when that is or why it keeps changing.

They’re both feeling the pressure to give in. If it’s an engineering-led organization, the salesperson usually has to back down. If it’s a sales-led organization, the engineer often loses their footing here.

As the product manager, you’re stuck in the middle as the mediator, trying to find the best balance that meets the needs of the business, and doesn’t lose the trust of either stakeholder!

How to fix problems stemming from misaligned incentives

Fixing this requires trust and a shared vocabulary. These team members need to be able to speak honestly about their incentives, and the trade-offs they are and aren’t willing to make.

Talk to the salesperson. What’s at risk if this misses the original deadline they were hoping to see this done by?

Sometimes there’s nothing truly at risk, though it gives a sense of eroded trust as they can’t see the value of the last mile of development (we all know how long that last 20% can take!). Enlightening them in the process, and showing them the value of having good quality, stable, secure, and documented code can often win them on to your side.

Sometimes their livelihood is at risk. Perhaps they’ve been unable to sell the current iteration of the product, and they are depending on this new release to be able to unlock sales and therefore unlock their commission. It’s a horrible thought to think that someone’s paycheck could dry up based on someone else’s pace of work elsewhere in the business, but it does happen. In this case, it’s important to escalate this issue, as that pressure does not belong with the development team alone. That’s a problem with how the sales team is being incentivized and the tools they are being given. The executive team should be aware of the issue and look to fix the issue. If the current product isn’t sellable, the sales team shouldn’t be on commission-based pay for sales on it, or else they will be incentivized to sell things that don’t yet exist! If the current product is sellable, the salesperson locked in this fight about hitting this deadline needs to be sufficiently trained in how to sell it, and refocused on those efforts rather than in places where they cause further tension.

If you don’t get support from your execs and salespeople in this tough conversation, there’s a possibility that your company is actually stuck in the Agency Trap, where the misaligned incentives go straight through to the core of the business model.

Talk to the developer. What’s at risk if you were to release a portion of what’s ready in the next release? This isn’t a threat, but a thought exercise. It’s a way to explore how work can be broken up into smaller chunks, if at all, or if it needs to go out in one piece. It helps to illuminate insights into what’s done and what’s likely to be left out. It’s important to listen carefully to your developer here, as they have expertise that’s usually not matched by others in their domain. Your job will be to help them translate these requirements into something that the other stakeholders can understand, and buy them time and space to crack on and get the important parts of their job done.

This doesn’t mean a middle ground can’t be found. These conversations illuminate where common ground is found, and a compromise can be reached that works for the business.

Perhaps the stakeholders agree on a time-limited experiment to be run, where some of the code is released so that it can be tested, but with the agreement that time is carved out so that the engineers can refactor afterward, based on how the initial piece of work fares. Perhaps the conversations help to realign the salesperson’s expectations and allow them to see a little bit more of how the product is built. Or maybe it’s just an agreement to get the engineer in on the conversations earlier next time so that these misunderstandings are avoided in the future.

Incentives run deep in our companies’ cultures

This might seem like a simplistic situation that you’d chalk up to a misunderstanding, but it’s fundamentally tied back to how the company is asking them to operate, and indeed how the company itself operates. 

See, some companies get stuck in a real short-term-ism mindset. They want to see results quarter-on-quarter, but don’t think about the long-term health or viability of their business. 

This results in, frankly, bad decisions being made about how to run things.

For example, think about your publicly traded, extra-large organizations. These companies have a fiduciary duty to maximize shareholder value. What this means in practice is that they want to see that stock going steadily up and to the right. It doesn’t have to be fast, it just has to be steady and predictable. After all, predictable is something you can invest in, and that’s really the value of a publicly-traded company, if you’re an investment manager.

So these companies are incentivized to keep those numbers moving steadily upwards. Any blips in performance—a few bad quarters—and the CEO is often turfed! That CEO has no incentive to try new, risky moves that might help them explore exciting opportunities or fend off growing competition. Their job is to keep the ship afloat and sailing straight— Maximize the revenues from the areas that already generate revenue, and keep costs down across the board. 

The best way that these companies know how to maximize revenues in each area and keep costs down is to break things up into siloes. That way, they can measure each thing independently and push and pull on levers where needed. 

But we all know siloes are not the way forward—they stifle innovation! 

Furthermore, they get divisions in a tight spot where they often start working against each other. You might have one team tasked with getting support call time down, and they are perfectly capable of doing that!…. Except that it makes another team’s customer satisfaction scores also dive bomb. Or have one team tasked with cutting travel and expenses, with the knock-on effect that sales and product people meet with customers less and therefore pick up less market knowledge. 

Are you working in a profit center or a cost center?

Some of the way that organizations treat their divisions comes down to whether they regard that division as a profit center or a cost center.

Profit centers are areas of the business where they know that they put money in, and revenue predictably comes back out. At the enterprise level, generally, the aim is to keep this engine running smoothly, and keep chucking more funding in. More sales, more marketing. As long as it’s working and they are seeing profit out the other side of the equation, the business will continue to invest heavily in this division.

Cost centers are necessary divisions that keep the business running, but aren’t seen as revenue generators. You put money in purely for the aim of keeping the rest of the business going, but you don’t expect a big return to come out of these investments. Typically, divisions like HR and operations are considered cost centers. 

And us in product and tech? Well, of course, we’re regarded as a cost center. Our R&D and discovery work is rarely thought of as an investment in the future for potential revenue growth, but a necessary evil, required to just keep the lights on for sales and marketing to do their job.

And it Explains. So. Much.

The job of the CTO often isn’t to maximize value to the user. It’s to keep costs down in the tech division. 

Think about all the measurements we’ve all lived by. Velocity. Burn down. Story points. These measure output, not outcomes. They are useful if you’re trying to squeeze as much productivity out of a tech team as possible, as quickly and cheaply as possible. They’re not going to help you figure out if you’re actually building the right things.

After all, you could finish lots of story points! Incredible velocity! Burn down charts like no where else! But all that’s saying is that you probably built a lot of features, at best. And everyone knows that a lot of features don’t make the best product. 

This way of working might control costs, but it optimizes for building features, not for solving problems.

It’s focused on output, when it should be focused on outcome.

The team is rarely left with room for discovery, and leads to the company often being blind to the bigger problems or opportunities in the space.

Think back to the likes of Blockbuster, who could have taken a risk and had the chance to acquire Netflix, but they didn’t dare take the leap. They were incentivized to stay the course.

Think back even further. Kodak themselves had the technology to take a real crack at digital photography, but didn’t have the incentive to do anything with it. They saw the revenue from their existing line of film products, and continued down their predictable track of investing in sales and marketing in those areas.

Neither of these companies, and many others like them, felt the need to explore what the future might hold. The way the companies were structured and how the execs got their jobs and their bonuses and their pay, there was no baked-in incentive to even consider it. Efforts to innovate from within were smothered, and eventually, these companies died.

Ultimately, incentives were the problem here. Incentives are almost always the problem.

So whenever something doesn’t feel right or isn’t running as well as it could in your company, really dive in to figure out what might be in the driving seat. Who is being incentivized by what, and how is that playing out in the dynamics of the situation? Use this information in your favor, to pull the right levers and present more compelling arguments—it might just save your business from a Blockbuster fate.

The post The Incentives Problem appeared first on ProdPad.

Do you ever feel like you’re getting pulled in two directions?

As a product person, I’ve often felt like I’ve had the pressure to deliver like a project manager. It’s a little like having an angel and a devil on each shoulder.

One is telling you to dive in and ask why, and to understand the problem deeper, and to maybe group together these two parts that solve similar problems into one… while the other is yelling at you to stick to the plan, to avoid scope creep, to just deliver on time and get the job done!

As a product person, you should cherish every moment you get to spend in discovery mode. This is where the big, juicy problems of the world are found and cracked, and real value is discovered. 

Delivery is when you’re honing in on that one problem, and is really more of a means to an end. You have to have delivery, as it ultimately pays the bills, but it’s not the earth-moving disruptive activity that discovery has the potential to be.

You have to have balance – you have to find enough time to discover problems, and of course, spend some time delivering on those solutions.

But what if this gets thrown off balance? What if you’re like me, and you end up starting out with great intentions to discover problems and interesting ways to solve them, but before you know it, you’ve got your hands tied with too many delivery commitments? 

About 12 years ago, I was a product person for a company in London. I was meant to join the team as a product manager, but after a week or so there, it became clear that I was really lined up to do a lot more project management than I’d anticipated. 

The company hadn’t knowingly mis-sold me on the job. They’d just gotten stuck in a trap that I now know is really common, as I see it all the time amongst other product teams that I spend time with. 

I’m here to warn you about it and hopefully help keep you from the same trap. I’ve delivered this advice as a keynote talk at a number of product conferences and events. If you want to take the learning away, feel free to help yourself to the accompanying slides They should help illustrate everything I cover in this piece and can help you talk through the ideas with your teams.

The Power of Product Discovery

Why is discovery so powerful?

Discovery is at the heart of what product teams do. The very nature is to cast a wide research net to identify problems and hold back from committing to a solution. The product team then has a process of, essentially, guessing and checking to optimize to find the best solution that’s cost-effective, desirable to the market, feasible to build, and valuable for the business.

It’s a process that can take years, and is messy, and doesn’t guarantee success by any stretch. But when it is successful, it pays off in spades. 

Contrast this with how agencies work. In an agency, a client identifies a problem for you and enlists your team to tackle the problem, and then you and your team get paid for that piece of work. 

The biggest indicator of your ability to scale is to look at what it is that you actually sell, as a business.

This determines whether you’re more of a product company or an agency. 

Agencies sell their time in exchange for money. This usually takes the form of client contracts and projects.

Product companies, on the other hand, sell value that they create. 

Time is the one thing we can’t create more of, it’s the ultimate limited resource, and so agency-style businesses can only scale with more human resources – more people providing more of their time to the business. 

Product companies are able to create value, by investing time upfront, into a mix of products or services that can be resold again and again, without needing a directly proportionate number of humans involved to scale. 

This is why product companies can go from start-up to scale-up and grow into such enormous tech giants, and fundamentally, why agencies can’t.

Now, there’s absolutely no shame in building and running an agency. It’s a brilliant way to make money and create purpose, solve problems, and get paid. But if you want to become a unicorn it isn’t the business model you need.

Product companies change the world!

But agencies don’t change the world. Product companies do! 

If you take a look at the companies storming the charts in the last decade, it’s tech companies who invest in scaling the product side of their business. 

Here’s a look at the S&P index, and how Netflix, Amazon, and Google are outperforming even the best of the best, with their product-minded approach.

And so, so many companies go in with this idea of building and scaling a product company, but end up in this same trap that I did in this previous job. 

Acting like an agency.

Taking on client jobs and commitments, and carving into their time that would otherwise be spent on discovery. 

And rather than take off, it can cause companies to sputter and fail.

What’s going on here?

How agencies work

Imagine you’ve got a business, and it’s got a monthly cost – let’s say this is you and 3 team members. And that’s you in month 1.

Assuming all things equal, this is you over the following months too. Low-cost team, but still a cost.

Now, you can’t go on spending forever, you need money. If you’re setting yourself up to be an agency, then you can take on work and start selling your time. 

If you’re any good at business, you’re selling your work at more than it costs you. 

Your cumulative sales go up, and your monthly profit is tidy but small.

Okay, so you want to grow your profits? You can grow your team! Then you’ll have more time to charge out for client projects. Your profit goes up a bit. Your growth is still a stick straight line, however. There’s no exponential growth in sight. 

If you wanted to be rolling in it, in this agency model, you’d have to hire and manage a lot of people.

How product companies work

A product company, on the other hand, has an entirely different way of working. 

They usually start off with a group of founders, and maybe some ideas and connections, but not a lot else. They’ve got a monthly cost, but aren’t selling their time in agency work. They’re investing it in a product that hopefully will sell in the future.

The cumulative sales is huge though. Once you’ve got something of value that sells, the sky is the limit. 

Yes, you’ll sometimes need to bring the size of your team up to support the growth, but nothing like the 1 for 1 nature you get with trying to scale an agency when you’re selling project hours worked. 

You might notice that I didn’t include the profit on this diagram. That’s because it’s probably still way below zero. 

This is the fundamental problem with product companies and what makes them tricky. In order to get to the point of having something that sells in a scalable way like this, it can take months or years. That’s months or years without getting paid. How does that work?

Well, this is why startup funding is so popular. 

It buys your team time to figure out what the product that creates value will be, so you can survive the months until you actually generate money of your own. 

Or, if you’re so lucky, maybe you have money of your own to invest in, or can live and work without a salary for a while, or have access to government grants. 

Okay, now this might seem really oversimplified, and it is, for anyone who knows their way around how startups work. But it’s important to keep in mind because I’ve seen even the savviest companies fall prey to this one trap.

See, there’s a danger zone. 

It’s so much easier and faster to make instant money in an agency-style business. 

If anything ever goes wrong in the plan, or heck, sometimes all it takes is a little bit of temptation, it’s easy to fall into this habit:

A client who comes to you asking for something a little bit custom. An offer of what would otherwise be a month or more of payroll in one fell swoop, and all it takes is you to stand there and say or do things that you already basically do for free for the company otherwise.

What’s the harm in taking on one little project if it lines your pockets or keeps the lights on?

Because what happens, is you go from envisioning this scenario, where you’re able to discover a problem, solve it well, and make lots of money before anyone turns up asking for rent…

To this scenario:

Your initial investment ends up running short, your costs are that much higher, and it takes longer than you might imagine getting to product/market fit. All of a sudden, you’re a dollar short and a day late.

Nearly every start-up starts off with great intentions of following a scientific methodology of measuring, learning, and iterating until they’ve solved the most valuable problems in the world.

But these go out the window in times of stress.

Sometimes, “whatever we need to do to get to the next round” actually becomes selling time for money.

Agency work, done by a team who has otherwise configured themselves as a product team. It solves the immediate problem at hand, which is preventing the lights from going out…

…but it also usually means that the product work gets delayed and delayed.

Because let’s admit it. Making money and cashing cheques is addictive.

After all, ideas are nothing, it’s all about the execution right? That’s the power of delivery.

Except that every minute of time a client buys to have you work on their problems is a minute you can’t spend discovering and solving the bigger problems in the world.

There’s a chance that the client happens to identify a problem that’s big enough to apply to a wider market and you’re able to solve it at the same time as solving for the paying client, but those chances are slim. More often than not, you’re really just in delivery mode, and you haven’t just magically leapfrogged months or years of discovery. 

Signs you’re veering into Agency Mode

So, as someone who’s been there, and has seen countless companies end up down this path, I can share some signs that your company is veering into agency mode. 

1. Sales Led Roadmap

The roadmap is such a telling feature of any company. 

In a discovery-led company, the roadmap should be a series of problems to solve and should facilitate the discussion of what could be solved and in what order, to fulfill the product vision.

In a sales-led organization, the roadmap looks more like this:

This is actually my roadmap, from years ago. 

The grey areas represented discovery-led work, where we were building for the wider market and trying to find the biggest, juiciest problems in the space to solve, and the best ways to solve them.

Unfortunately, our time was dominated by the work in the green strip, what we called ‘Enterprise’ and ‘Partner launches’. These were things that we were doing to close specific deals by specific dates. 

Sure, it got us paid that month, but look at what the cost was. For the preceding quarter, in particular, the month and a half before this roadmap was generated, we basically did nothing to further the vision of our core product. All of our work was tied up in partner work.

And while it looked like the partner work cleared up in the future, it never did. Our salespeople were always coming back with a big grin on their face to tell us about the next thing that they’d sold, only for us to find out it required work on the roadmap to make it fit. Ultimately, we didn’t do a fraction of the discovery work this roadmap suggests we were going to do in the future. Ultimately, this business failed. 

A discovery-led roadmap looks entirely different.

It’s centered around business objectives to meet, like revenue or user targets, and customer problems to solve, and the product manager uses the roadmap to make sure that things are prioritized to make the most use of resources, and are spending time discovering in the most interesting and valuable problem areas first. 

It’s not overrun by client commitments.

2. A Product Manager who’s actually just a Project Manager

Another sure sign that you’re veering into agency mode is when your product manager is having to act the part of the project manager. 

A project manager’s job is to gather requirements, figure out the scope of the project, and then guide the project through to completion, managing resources, milestones, delivery processes, and other constraints along the way.

I’ve been in this position, where I was hired as a product manager, but found myself sat in front of clients essentially taking down a list of requirements and helping to write up quotes for custom work.

I’ve spent far too much of my time breathing down the necks of development teams, trying to get estimations, and creating “accurate” buffers to report back to the sales team and clients. 

This was all time that I couldn’t spend figuring out if there were bigger problems to solve, and how we might be the ones to solve them.

3. Feature Factory

Another sign you’re veering into delivery mode and out of discovery is that you’ve become a feature factory. 

This one is so easy to fall into, as it starts when the company is young. 

In the early days, each new feature gets you more downloads, more press, more sales. It improves your product, measurably.

But over time, each new feature begins to weigh you down. It doesn’t give you the same boost, and you end up with a Frankenstein of a product. 

We’re addicted to our features. We can’t quit the habit of building features because of the pressures from those around us.

• Like the salesperson saying they can’t sell the product without that one last feature
• Or your marketing bod pointing out that you’re lacking a feature that would mean some vital checkmark on their pricing grid
• Or that inner voice that tells you that you just need this one thing to tip your numbers into a viral growth loop
• Or the eternal question from your board, your boss, your customers, from everyone: When is this coming out?

Teams stuck in a feature factory are constantly chasing the next idea and spending a lot of effort on getting work out the door, but not a lot of effort on making sure that they are doing the right work in the first place.

Some typical patterns to watch for include:

• Having very specific ways of prioritizing the ‘right’ idea, but those methods tend to be very sensitive to changes in the market or even opinion
• Lots of emphasis on moving quickly and getting work out the door. Watch for terms like ‘agile cadence’, ‘burn down’, ‘velocity’. These are delivery metrics that measure your ability to ship fast, but not the ability to ship well or to discover the right things
• Very little time granted to validating that past launches were successful and impactful and that the right things were actually shipped. A common habit is to launch ‘experiments’ but not actually check the results

A better approach is to take a step back and prioritize at the problem level, not at the idea level. 

This tends to avoid the trouble of getting stuck in a very granular priority system (like stack ranking or weighted scoring for ideas), and instead allows your team to focus on the company-level objectives and figuring out the order in which to tackle the problems and opportunities ahead. 

It helps to prevent your team from being distracted by that ‘one feature’ that will woo a client, and instead focus on the big picture.

How to get out of the Agency Trap!

So how do you go about getting out of this pattern?

Acknowledge it and have tough conversations

If you recognize that you’ve been doing this, bring it up with your team, and make sure that it’s acknowledged at the exec level. It’s often a tough conversation, as it means admitting that sacrifices have been made, but it’s important that everyone in key roles in the business knows what’s happening and how it impacts the outlook of the company.

Set your ideal outcome: What kind of company do you want to be?

As part of that conversation, ask and answer the question: What kind of company do you want to be?

Perhaps taking on lots of client work is all part of the plan, as the company actually does want to operate more as an agency in the future. That’s okay! It’s better that you all know that now, and can adjust your roles and expectations accordingly. 

Perhaps the aspiration is to be a huge tech company, and these short-term delivery commitments are just a means to an end. That’s okay too. We’ve all been there. It’s totally okay to take on some work like that, if it means not having to go for a risky round of funding, or if it enables you to grow the team to get to the next stage. 
It’s just really important that you have these tough conversations and align everyone in the team with what the ultimate goal is so that the best strategic decisions are made, and everyone heads in the same direction.

Rearrange and train the team where needed

This is the toughest step. 

You might have a salesforce who’s out there selling future versions of your product that you’ve decided you no longer want to commit your team to delivering. 

You might need to repurpose this team or rightsize this division to match your now clarified company aspirations.

You might have team members who are ingrained in the delivery mindset, who aren’t used to or prepared for a discovery-led process. You’ll have to work at the exec level to make sure there’s adequate support and training so the team doesn’t flounder when given a little bit of free rein for discovery.

Separate agency work and charge accordingly

Separate your agency work into a different business unit along with its own space for custom work.

Charge separately for this, and charge well! Remember that time is the most limited resource you have. If someone’s asking for custom development, do not be afraid to ask for eye-watering fees for the honor.

Remember, they are buying time that you could otherwise be using to be building your rocket ship. Their alternative might be any other development team out there… but is it really?

They are probably coming to you for custom development because you built something special and proprietary in the first place. You might be the only team in the world actually able to give them specifically what they want. Their alternative, if they don’t buy the product as is, or don’t pay your handsome fee for custom work, is to spend years rebuilding your product and then doing the custom bit on top themselves, or finding some other team to do this for them.

Sure, they might go with a competitor, but there’s a reason they are asking you. And sure, you might lose some deals this way.

But remember, you’re a product company. You’re selling a product that you’ve created. You’re not an agency at heart, selling your time. 

Otherwise it’s not worth your time! Charge way more for the clients you keep and get rid of the time-wasters.

Decrease dependence on project delivery cash

And finally, decrease your dependence on the cash that comes in from committed client or contract work, by being deliberate with how much time you spend in delivery and discovery. 

If today, it’s 80% delivery and 20% discovery that takes up your team’s time, can you get that to a 70/30 split by next month? When can you get that to a 50/50 split? 

Plan out steps in your strategy that look at how you’ll build up your core product so it’ll sell more and more, so that you’re less dependent on external funding from clients and custom work, and more free to solve problems in the core product itself. 

It won’t happen overnight, but nor will it happen by itself. It will take you and your team to gather around, admit there’s a dependency on agency mode work, and a concerted effort to make a plan to get away from it.

Final note

But remember, you don’t have to go product! 

There’s a big world out there and lots of ways of providing value. If you’re going to go the agency route, then acknowledge it, own it, hire for it, and do it properly, including setting pricing and expectations accordingly.

Don’t fall prey to the most common killer of product companies. Product companies get sucked in by the allure of agency work because it solves an immediate problem in the near term but forces them to take the eye off the ball. 

If done well, it can bridge them elegantly to their next stages and on to success.

But if done badly, it can doom your company.

Start acting now, to identify and work towards building the type of company you want in the future.

Just remember to ask yourself, what kind of company do you want to grow up to be?

The post Avoiding the Agency Trap – Product Led Companies Scale-Up appeared first on ProdPad.

We’ve written previously about how OKRs are used to align your team around the same set of goals. However, there are a few points product managers need to be mindful of when implementing OKRs into their product strategy – especially those in high-level positions.

1- It’s an objective. It’s not simply a goal

An objective is an actionable target that clarifies the desired outcomes. A goal tends to focus more on measurable outputs or milestones. Product objectives contribute towards achieving wider company-led goals, and the connection between them would be outlined in the product strategy.

2- It’s a key result. It’s not a key performance indicator (KPI)

Key results focus on the direct outcome of specific activities (or initiatives) which can be measured and learned from. KPIs are more commonly used to measure the continued success or progress towards a defined performance measure, not an outcome-focused objective. A lagging KPI may well lead to a discussion to identify a future objective (complete with the key result) to improve it.

3- Initiatives are something different, too 

An initiative describes the specific activities or projects the team is working on to influence the success of an OKR. Even if you identify what you need to achieve (the objective) based on the company strategy and determine what good looks like (the key result), you’re not going to get very far if you’re unable to clearly communicate the actions you plan to take in order to get there (the initiative). 

Let’s use this as an example:

Objective: Improve your overall health to avoid illness or injury

Key result: Lose 15 pounds by the end of 2020

Initiative: Exercise for more than 30 minutes at least 4 times per week

4- OKRs don’t always have to cascade 

OKRs should not be put in place to control teams and trickle-down keeping everyone in check. They are used to unify teams, stretch yourselves to achieve greater things, and ensure that everyone is moving towards the same destination. Specific product objectives do not need to be entirely derived from  those at the group level. It is the product manager’s job to make sure their OKRs are directly linked to the outcomes their products are seeking to achieve and not last week’s departmental leadership meeting. ProdPad can help you avoid this issue through the product and portfolio canvases. The portfolio canvas establishes the vision, high-level strategy, and approach to achieving the objectives for the entire portfolio of products. Some, but not necessarily all, of the product objectives should align with and help achieve those portfolio-level objectives.

5- Don’t lose sleep over the stretch target 

Objectives are there to point you in the direction you aspire to go down. If you hit 70% of your stretch target then that should be applauded. You’re trying out something that hasn’t been done before. As long as you are testing and making informed decisions a reduced achievement won’t be massively detrimental. Be sure to record the outcomes of each OKR so that you can learn and improve. This will help you reduce risk in the future and operate on a more cost-effective basis. 

6- Avoid gamifying objectives and key results

It’s important to remember that OKRs are not there as targets for the individuals in your teams. OKRs measure the overall success of the product’s performance. As a leader, it is not best practice to start trying to hide targets under your OKRs. This will stifle innovation and growth as team members will end up gaming the system to improve their individual performance. One great way to combat this is to build in counter-metrics that pair a quality metric with the quantitative key result measure. 

When done well, with buy-in across the entire organization, OKRs can be a valuable tool to increase alignment, foster innovation, and propel your teams to greater success. Looking to implement OKRs into your own organization? Book yourself in for a free demo where our product experts will be happy to help. 

The post Six Pitfalls to Avoid When Implementing Objectives and Key Results appeared first on ProdPad.

This is the story of how it was invented in a cafe in south London.

Years ago, when I started as a junior product manager, I fell into the role by accident, as many others did. With little training or guidance, I learned a lot by doing or Googling.

One of the first things I came across was the concept of the roadmap. All of the examples online were of timeline roadmaps – essentially Gantt charts. This felt pretty intuitive to me, having had a little bit of training in project management. After all, who doesn’t like the sense of control that a Gantt chart gives you?

Creating a roadmap

I set off on creating my own roadmaps – at first, on paper and whiteboards; soon, digitized in various incarnations: PowerPoint, Excel, and even Microsoft Project played a part in my early misguided product management efforts. 

I didn’t realize my efforts were misguided; my bosses certainly didn’t give me any guidance otherwise. As a matter of fact, they essentially gave me a pat on the head for my colorful, visual timelines of the upcoming product plans, and sent me on my way to go deliver. I don’t think they knew any better either.

Many of you reading along probably know what happened next (as product managers): Deadlines whooshed passed and timelines slipped. Turns out that delivery is hard, especially when you’re hanging your assumptions on made-up estimates! 

At that stage in my career, I didn’t feel comfortable speaking up as a product manager. So I course corrected by adding more buffer and covering for the slipped work. Don’t tell me you haven’t done this too – we all have.

The net result: The added buffer meant that delivery timelines slowly stretched out. We all know that work expands to fill the time given to it. So, the scope would creep, and work would slow down just enough to cause further slipping. I’d have to add more buffer or have to explain to my bosses again why we weren’t delivering on time. It was an insidious, vicious cycle.

And I was sure I was the only product manager who was so bad at her job that she couldn’t deliver a roadmap. I mean, wasn’t everyone else simply making roadmaps, building the features, launching like a boss, and killing it out there?

That’s what it felt like in 2009, and no one was talking about failure in a real way yet.

What changed?

In early 2010, I met Simon Cast, a fellow product manager, at a light-hearted social charity event in London. It was a rarity to run into another product person in those days. We relished the chance to chat and share some stories of our experiences. 

I pointed out that there was a lack of places for product people to meet. This led me to suggest that we work together on running the first ProductCamp in Europe. We went on to run ProductCamp London along with some other product people, just a few months later. This was how we connected with Martin Eriksson. He was just formulating the idea of ProductTank at that time, and we went on to co-found Mind the Product together.

In the meantime, I’d been harboring an idea for software to help me streamline my job as a product manager. This included the roadmapping aspect and the even more tedious spec-writing aspect. I’d even gone so far as mocking up some prototypes and giving the software some names. 

Embarrassingly, I’d gone with Spec-ify for the spec-writing tool and Map-ify for the roadmapping tool.

Simon gave me feedback and advice on the software concept. He helped shape it into a single tool that did both idea backlog management and roadmap management. He brought his skillset in back-end development, combined with my experience with front-end (though my abilities with JQuery are and remain dubious!), and we began building the first version of what was to become ProdPad! 

Simon and I both held roles heading product at different startups in London, and we built ProdPad in our spare time and on our own laptops. We used it to help us do our jobs more effectively.

We had a lot to learn, as this was still a timeline roadmap.

It wasn’t until we started taking our slightly more-market-ready version of ProdPad out to the product people we knew in our circles that we spotted our fundamental error.

You see, we still thought that we were the only product people who weren’t delivering on roadmaps. However, when we released an early version of ProdPad, our eyes opened when we got early feedback: About a month in, our most popular request was to be able to shift multiple items on the roadmap at the same time. 

Had we simply listened to our customers at face value, we might have enhanced the functionality of the roadmap with a multi-select drag-and-drop function so that they could do just that.

But instead, we asked a bunch of why’s

When we got to the bottom of it, it became clear that no one was delivering on the roadmap. The request to move and manipulate multiple items on the roadmap at the same time came from the desire to adjust around slipping timelines and missed deadlines. 

So we asked ourselves: If no one is delivering to a timeline roadmap, what’s the point of the roadmap for a product manager?

I’ll admit that we held on to the timeline format for a few extra months longer than we should have. Sunk cost fallacy, you see. We’d invested a lot of our time building this thing, an all-singing, all-dancing JQuery behemoth that allowed you to add features to a timeline roadmap, stretch and shrink them to the appropriate dates, and drag them into swimlanes. It was incredibly hard to admit that we had been doing our product management jobs wrong for years and that we’d built a useless, misguided tool, and wasted months of work in the process, even as the customer feedback stacked up.

But the feedback was in, and the timeline had to go.

We got together at a cafe that was about halfway between our homes, in south London. Wandsworth, to be precise. (This was long before we had an actual office, after all!) It was nearing the end of 2012. 

We talked about what a roadmap was and what it wasn’t.

A roadmap is a communication tool. It’s strategic. It aims to keep the team aligned and informed about the steps that are needed to reach the product vision. The roadmap needs to show some concept of upcoming initiatives. It should show how it’s connected to the problems the team is meant to solve, and the objectives they are meant to hit. 

A roadmap isn’t a list of features and bugs and work in progress down to the day and week and month. That’s a release planner. 

Simon turned over his napkin, and sketched out three columns:
Current | Near term | Future

He talked me through a concept of time horizons, and three ‘buckets’ with initiatives that could group together ideas, features, or experiments. His concept was underpinned by the idea that initiatives in the Current column were more certain, while the ones in the Future were less certain and fuzzier in scope.

Simon and I both liked the freedom that this format gave, while still delivering on all the points that a roadmap needed to have, to still ‘be’ a roadmap.

We passed the napkin back and forth and made some notes and agreed on a simplified version. I would knock it together with simple front-end code, so Simon could hook it up on the back-end. 

We shuffled the timeline roadmap code to the side. This was an experiment after all, and we had no idea if it would work.

One piece that we didn’t talk about was whether we would still call it a roadmap. We didn’t think about it at first until we saw the result live on the page – a three-column time-horizon roadmap, meekly standing where a timeline roadmap once stood. We debated renaming it but didn’t know where to begin. After all, our website said we had roadmap software, and it did technically meet the criteria. Our new roadmap format was just… different.

Somewhere along the line, the napkin was lost. I wish I’d framed it now.

We launched with no fanfare, as you do when you have no paying customers and a simple MVP bootstrapped product that you built from your bedroom. But our early testers took note.

And they actually liked it! 

What we discovered in our next rounds of feedback was that the format allowed product people to communicate the bigger picture. After all, most companies don’t know how big they’ll be in a year’s time, let alone how fast they’ll be able to deliver! 

Our first version was very MVP. It was simply some boxes you could add to one of three columns pragmatically named ‘Current’, ‘Near Term’, and ‘Future’. Frankly, you could have done it in Trello. The basic format grew into a much richer form of lean roadmapping.

It was right to keep the name ‘Roadmap’ for this new format, even if it didn’t look like the other roadmaps. From feedback, we realized that we were implicitly giving product people permission to step away from the timeline roadmap format. After all, they were giving their team and their bosses a roadmap. It said so, right there at the top of the page, on a real dot com SaaS product, so it must be legitimate! 

By subverting the format and terminology we changed the way that roadmapping was done. Which we appreciated sometime later. It’s a roadmap. But it’s not a usual format roadmap.

We still had a long way to go to find out if our way was any better. We had a lot of listening and learning and iteration ahead of us. 

The Modern Roadmap Evolves

The basic scaffolding of the new roadmap format worked. New testers gave us positive feedback about the time horizon concept regularly. We set out to figure out what we needed, as the functionality of the roadmap was severely lacking.

Since then, over the years, the roadmap has evolved.

• You can link initiatives to ideas in your backlog, so you can see what experiments your team might run in order to tackle each problem on the roadmap
• We made these ideas sortable and then made the workflow stage visible so you could see if it was in discovery or in Jira or wherever else
• We created colorful labels, so you could associate initiatives with objectives. Later, we gave these labels text fields, and later still, we allowed you to link an initiative to multiple objectives
• A set of filters lets you carve up your roadmap into specific views suitable for the job at hand
• We created options to publish and export your roadmap, so you could create versions for your exec team, your sales team, or anyone in between in a flash
• We introduced the concept of product lines and a portfolio view of your roadmap, allowing ProdPad to scale for use in much larger enterprises

These and many more iterations have allowed us to evolve and improve the roadmap in line with today’s best practices. We’ve learned a lot, and continue to learn as the discipline of product management grows and develops. As we move into a new decade, we’re excited to see what comes next! We do not rush to follow the crowd. Through measured, and considered steps forward, we build the right solution, even if it’s not what is expected.

What’s in a name?

Along with evolving the roadmap functionality itself, we’ve seen a lot of change over the decade in how we talk about this new form of roadmapping.

We didn’t know what to call it when we first launched the new roadmap. We just kept the name as is, simply calling it the Roadmap. Internally, we were calling it the ‘time horizon roadmap’, and in conversations with potential customers we would talk about our ‘dateless roadmap’, but none of these ever had a ring to them.

Later on, as the concept caught on, we started hearing about other terms that rang true to our purpose. In 2013, Bruce McCarthy started talking about the idea of using themes on the roadmap. He launched that term into popular consensus: through conversations, he had with Jared Spool, an MTPcon talk, and an article. Problem-focused roadmaps had been simmering under the surface for some time. We all knew there was something inherently wrong with the feature-based roadmap. We were lacking the tools and techniques and vocabulary to do something better.

Theme-based roadmapping was a popular term for a while. We watched it evolve into various other names, including Problem Roadmap, Objective Roadmap, Outcome Roadmap, or as we like to call it, as it derives so heavily from the Lean principles of ongoing learning, the Lean Roadmap. Bruce went on to write the very popular and timely book Product Roadmaps Relaunched, with several other product luminaries. I wrote the foreword, which was an honor. Even more thrilling was seeing the ProdPad Now-Next-Later format roadmap touted as useful in a full-page spread case study. It’s smack in the middle of the book!

It’s been a long journey of discovery. But we’re on the right path, and we’re building the tool that actively helps product people do their job better. I can’t wait to see what we learn in the next decade!

Are you a product manager? If you have any burning questions or want to talk all-things-product, then get in touch. Or, give ProdPad a try by signing up for a free trial.

Looking for more PM advice? Try our product management blog for more top tips.

The post The Birth of the Modern Roadmap appeared first on ProdPad.

Company objectives, team objectives, personal objectives, product objectives… So many objectives! One particularly troublesome problem for anyone involved in product development is the confusion between company objectives and product objectives.

We should start by defining what we mean by objectives.

Objectives are outcomes that show you are delivering the strategy that you have defined in order to achieve your vision. This applies for either company objectives or product objectives. And it is also the key difference between product and company objectives. Your company objectives are derived from your company vision and company strategy while your product objectives are derived from your product vision and product strategy.

Product Objectives

So before you arrive at your product objectives you need to start with your product vision and define your strategy. Then can you can come up with product objectives whose outcomes show that you are delivering your product strategy.

Let’s go through an example

Say our product is a smart thermostat for electric heaters (yes, I’m cold). Your vision for the product could be:

“MakeItWarm is to be the smart thermostat that puts the user in secure control of sustainable comfort of their homes or business. This will be achieved by allowing the user to set their comfort zone via multiple devices and will teach them how to provide that most sustainably.”

With the product vision detailed, next you should define a strategy that will allow you to achieve that product vision. A strategy is best defined as a series of outcomes that will indicate you are achieving your vision.

Continuing our example the strategy could be:

“Our strategy to deliver this product vision is to:

• Provide a Wifi/Internet connected thermostat that is easily installed by the user
• Provide a usable interface on multiple devices
• Support multiple forms of heating and cooling
• Partner with renewable and sustainable energy suppliers to provide users with the opportunity to switch supplier depending on demand and need”

These outcomes can be thought of as the strategic objectives. From these strategic objectives come tactical objectives or shorter term goals that help to achieve the strategic objective.

Let’s take the strategic objective of “Provide a usable interface on multiple devices”. This could then have a more tactical objective of:
“Implement a web based UI for the thermostat”
or
“Implement native mobile app for Android and iOS”

Both are objectives that help to achieve the overall strategic objective.

Company Objectives

But how do product objectives fit in with company objectives?

These two types of objectives often end up being used interchangeably, even though they’re not the same. This is particularly common in single product companies. The key to understanding how they fit together is to firmly separate company objectives from product objectives.

Company objectives are derived from the company vision and strategy for building a successful company. Product objectives, on the other hand, are derived from the product strategy and vision. This will be different from the company vision (of course the product vision must support the company vision).

Examples of company objectives are “Increase conversion from basic subscription plan to premium for users who have been with us for one year”, or “Increase margin on each thermostat”. Company objectives can be achieved through the effort other teams in the business – such as sales, marketing and customer success – rather than only through product or service.

Company objectives are focused on company outcomes and product objectives are focused on user outcomes. There is the potential for conflict between the objectives: you can do work that is valuable to the company but detrimental to the user, and also do something valuable for the user that is detrimental to the company.

Company objectives should feed into helping you work out which of the product objectives should be the focus within a specific time period. This helps you to prioritise your roadmap based on the product objectives which are linked to the initiatives or themes on your roadmap.

Achieving Success

If our product strategy is based on achieving objectives, how do we know that it’s successful? That it’s delivering the product vision? For a subscription-based business that is measured by looking at conversion and churn, if the conversion rate is going up and churn rate is going down, then the strategy can confidently be said to be working.

Or can it?

Conversion and churn can be affected by factors other than the product. For example marketing may have found a rich target market which is bringing the right people in or customer success could be actively spotting people likely to churn and helping to prevent this.

This is further complicated because improvements in marketing, sales and product reinforce one another. For example, finding the right target market for a product may result in feedback which improves the product, and makes the marketing more effective. So you can’t simply say x% is due to marketing and y% is due to product.

In reality conversion and churn are representative of the company’s success. They’re not representative of a user’s success with the product, and a user’s success with the product is the measure you need to show that the product strategy is working. Churn and conversion are simply proxy measures that you are solving the user’s problems, although they may represent good company objectives.

You should define up to three metrics that are indicative only of user success. These metrics will need to align with your strategy and objectives in order to be usable. In our smart thermostat example, the metrics that indicate user success are “Energy bill is lower than the same time last year” or “House temperature remained in the comfort zone without user having to manually intervene”.

Untangling product objectives from company objectives is crucial in making sure your product delivers for your end users. The two are often conflated in single product companies but you must work hard to separate them and ensure they remain separated. Start with the product vision, define the strategy and then create your product objectives.

Can you manage a product solely on objectives? Find out in the next in this series of blog posts.

Our product management blog has even more articles on a range of PM topics.

The post Company Objectives vs Product Objectives: Spot the Difference appeared first on ProdPad.