01
Sep 16

Mental Models for Product Managers – Part 1

The importance of mental models

Knitted Brain Hat

Model of the brain – in yarn (CC 2.0 by Linden Tea)

There’s been an explosion – at least in my feed – of folks talking about the importance of having a lot of good mental models to help you make better decisions.

A lot of this goes back to a talk by Charlie Munger at USC Business School in 1994. He’s the other old white guy who works with Warren Buffet at Berkshire Hathaway making lots of high-payoff investments. Munger said their “latticework of mental models” is one of their core competitive advantages.

What is a mental model?

“Any concept that helps explain, analyze, or navigate the world.”

I’d also add, specifically

  • That helps you make better decisions
  • That guides you on how to take better actions

Mental models are like tools in a toolbox. If you have only a few tools, you can only solve a few kinds of problems. Like the famous saying – If you only have a hammer, then you have to treat every problem as a nail. If you have a full toolbox you have a lot more flexibility and subtlety about how you can go after problems. And tools that aren’t quite up to the job is almost as bad as not having the right tools. You can’t fix a sink if you don’t have some plumbing tools.

Mental models can also help compensate for your own limitations. We all have limitations in the way we think which mental models can help address. They can be like a mental checklist, or like a jig or fixture. Things we know we should do but forget, or things we normally don’t think about but know we should.

Mental models comprise different types of things: heuristics, “cognitive laws,” templates, categorizations and categorization strategies. And there are hundreds if not thousands of mental models. Munger says “80 or 90 important models will carry about 90% of the freight in making you a worldly‑wise person.”

Mental Model Examples

Some general purpose mental models are very useful for product managers. This short list is taken from a fantastic list of mental models by Gabriel Weinberg:

  • Cognitive bias – and all the particular cognitive biases that arise in different situations.  “Tendencies to think in certain ways that can lead to systematic deviations from a standard of rationality or good judgments.” (See list of cognitive biases.)
  • Ask Why Five Times – Arguing from First Principles .  “A first principle is a basic, foundational, self-evident proposition or assumption that cannot be deduced from any other proposition or assumption.”
  • Scientific Method .  “Systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.”
  • Order of Magnitude.  “An order-of-magnitude estimate of a variable whose precise value is unknown is an estimate rounded to the nearest power of ten.”

You’re probably familiar with these and many more like them already.

Mental models for product managers

What about mental models for Product Managers specifically? There are quite a few mental models about products and making them successful. Too many to cover in this post, which is already getting long, so stay tuned for the next post.

What mental models do you use and depend on for getting your job done?


22
Aug 16

Selection Criteria for Product Management Tools

Tools For What We Do

As a product manager, I’d like to find some tools that help me do my job. I deal with:

  • Customers – finding their problems and listening to their product feedback
  • Markets – my segments, their problems, and how to reach them with my solution (and if they are big enough for me to make money)
  • Positioning and value propositions – what my product does for my segment, and why it’s a better solution than the competition
  • Strategy – how the goals of my company drive the solutions I deliver, and how my solution aligns with those goals
  • Revenue and profit – how my solution will generate top and bottom line dollars
  • Roadmapping – how my solution will be shaped over time
  • Competitors – who my competitors are, their strengths and weaknesses, and what I need to do to take advantage, or overcome gaps
  • Prioritization – out of all the features and solutions I could deliver, which ones should I deliver?
  • Go to market – how my potential customers hear about my solution, its value to them, and why they should buy my solution instead of our competitor, or instead of doing nothing

And oh, yeah:

  • Building a solution – addressing the customer’s problem effectively with technology, with enough differentiation that it’s possible to sell successfully

Tools for building the solution and managing that process are a dime a dozen.

But tools that help me with all those other things? Practically nonexistent. Mostly I have to use Word, or Confluence, or spreadsheets, or just my big brain, to manage all that.

My Selection Criteria

If a tool really cared about product managers, it would understand:

  • We have customers
  • Revenue is interesting
  • We do a lot of market research
  • There is competition
  • We have to take our solutions to market

And it would help us prioritize our solution based on those.

What You Can Do

  1. Irrespective of your tools, you need to keep all those things I listed in mind as a product manager.
  2. If your tooling doesn’t understand our domain specifically, you will need to augment whatever you are using to capture and manage that information. You can use templates, best practices, or just the power of your mind.
  3. If you’re evaluating or testing product management tools, make sure to ask the vendor about the topics I list above. How does the tool support your customer interactions? Your prioritization? Your value proposition?

01
Jan 16

2016 – More Hardcore Product Management Ahead

Calendar, by Joy (CC 2.0 license)

Calendar, by Joy (CC 2.0 license)

The turning of the calendar itself has no real meaning, but it does give us a chance to reflect on what’s gone before, and what’s ahead. In my last post I reviewed the topics we covered in 2015. This post is about where I’ll be focusing in 2016 in terms of becoming a more skilled product manager, and in helping others achieve that. I already “practice what I preach” on all those topics, of course. But there’s always room for improvement, and as I’ve mentioned lots of times, getting more effective at product management has a huge ROI.

Systems

But instead of focusing on that goal this year, I’m going to focus on a system for being a better product manager. This approach is inspired by several writers and speakers I heard this year, including James Clear and Dilbert cartoonist Scott Adams (on his blog and on on Tim Ferriss’s great podcast).

The idea is the system is what gets you to the goal. You still have the goal (maybe), but you pay attention to the system. These other guys explain it better than I do – for example, James Clear illustrates the difference between goals and systems like this:

  • If you’re a coach, your goal is to win a championship. Your system is what your team does at practice each day.
  • If you’re a writer, your goal is to write a book. Your system is the writing schedule that you follow each week.

In 2016 I’ll be working on my system for being a more effective product manager. As my new and updated system components unfold, I’ll report back.

Deliberate practice

The other big focus for me this year is “deliberate practice.” Deliberate practice is a key part of Kathy Sierra’s “badass” concept, although I didn’t go into great detail on in my badass-related posts.

If you want to become better at something, you have to practice – it’s true of skiing, it’s true of photography, it’s true of playing a musical instrument. And it’s true of professional careers as well – surgeons practice a lot, and so do lawyers. And practice is not just “doing the job.” As Kathy Sierra says in her book Badass:

Only a specific type of practice makes perfect, and in the science of expertise, it’s known as “Deliberate Practice.”

James Clear says, building on Kathy Sierra’s description:

Deliberate practice is when you work on a skill that requires 1 to 3 practice sessions to master. If it takes longer than that, then you are working on something that is too complex.

There are examples in the literature of doctors performing deliberate practice, and of course top musicians do a ton of it. But I haven’t heard of a pedagogy for product management that uses deliberate practice. It seems worthwhile to focus on this for a while, both for myself and for the product management community as a whole.

Some examples that have come to mind so far:

  • Making phone calls to stakeholders – this is actually something I’m not as skilled at as I’d like to be. Once I’m on the phone I’m fine, but it’s more of an effort for me to pick up the phone than it should be. So I think deliberate practice will help me with this.
  • Entering defects – this is something we all have to do as product managers, and I’ve actually done quite a bit of practice on this one.
  • Various situations where deliberate practice will take the form of role playing: breaking bad news to a customer, telling a sales person that the product can’t do what they just promised a prospect, breaking the news of a schedule slip. Those are all bad situations, but it will probably pay off to do some practice on how to make the best of good results as well – writing an effective company email to share an exciting customer success, for example.

I will develop a set of these small product management activities to practice, and then determine the forms that the practice will take. And then do the practice myself over the course of the year. It should be very interesting. And I suspect my skills will be much more developed at the end of the year.

 


31
Dec 15

2015 Year In Review – Hardcore Product Management

sparklerLooking back over 2015 on this blog, I see quite a lot of meaty content! The topics have been hardcore product management-related. I hope you’ve enjoyed reading it as much as I’ve enjoyed sharing it.

Summarizing (with links to the key posts), we went deep on:

I even put a product management maturity quiz out there, just for fun.

I have lots more thoughts to share in 2016. Tomorrow I’ll share some ideas on how I’m going to run things in 2016 so that more of my thoughts make it out into the blog and into the world. (The key word is “systems.”)


15
Dec 15

Interview With Hubert Palan, CEO of ProductBoard, Part 2 – Podcast Season 2, Episode 2

This second part of our interview with Hubert Palan is the third episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).

This is part two of our interview with Hubert Palan, found and CEO of ProductBoard, and long time product management leader and executive.

Part 1 of the interview is here.

Three things you can start doing today

As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from our interview with Hubert.

  1. Create a central repository, not just about the features you’re building, but about the market inputs you gather to help you find and validate the business problems you are solving. You can use a tool like Hubert’s ProductBoard, or you can try to roll your own (Nils had a podcast about this last year). This information comes from Support, Design, Product, Sales, Marketing, and your own conversations with customers and prospects. A central store of this input, and the relationships between this information and the product decisions it supports, helps mitigate some of the cognitive biases Hubert mentioned. And by gathering all this information together, you are better able to detect market signals in all the noise, and make better holistic decisions about the product.
  2. As Hubert pointed out many times in the interview, Context is King. Make sure your team, and your whole organization, knows not just what features you’re delivering, but what problems those features solve, and for whom. This not only simplifies many of the issues of prioritization, it also serves as a basis for communicating across segments of your organization.
  3. Clarity and communication are the heart of the Product Leader’s role. The better we get at clearly communicating about prioritization, context, and decisions made in the product team across the organization, the better the organization can execute on creating and selling solutions to customers.

Thanks to Hubert!

Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.

As always, we’d love to ask two small favors from you:

  • First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can access the podcast directly on this feed.
  • Second, please rate the podcast on iTunes or “recommend” it on your podcast app.

Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.


15
Dec 15

Interview With Hubert Palan, CEO of ProductBoard – Podcast Season 2, Episode 2

Here is the second episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).

Introducing Hubert Palan

Nils first met Hubert Palan in November 2014 at the Product Management Summit in San Francisco. Nils was presenting some ideas on a “roll your own product management system of record,” while Hubert was there to talk about the product he was building – a real product management system of record. This product, ProductBoard, is now available, and it’s definitely worth checking out. Hubert is a serial entrepreneur, with innovative and incisive ideas about how product management as a discipline can be improved.

In this wide-ranging interview, we discuss Hubert’s background, how he moved into product management, his career at Good Data, where he was the VP of Product, and his decision to leave Good and start ProductBoard.

This post is Part 1 of our interview, Part 2 is here.

Three things you can do today

As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from the first part of our interview with Hubert.

  1. Get in the problem space, not the solution space. Immerse yourself and your team in the problem that needs to be solved. Then, don’t devote so much of your time to the design and the solution – that’s a job for designers and engineers. Your advice and review is valuable, but your focus should be articulating the problem, then giving the rest of your team space to solve it.
  2. Turn your company or tribal knowledge into a system. It’s valuable even before it’s perfect. Think about team knowledge, the captured information you have, as something that deserves a system of record. Hubert described how difficult it is to simply use your memory for this, especially when it’s more than just you on the team. Of course, you can take a look at Product Board, but as Hubert pointed out: the system matters less than simply getting something in place.
  3. Finding the problem is orders of magnitude more important than how efficiently you can create a solution. Although it’s hard and not very well-defined, the process and results of focusing on the problem first will save time and frustration for many cycles to come, and often result in better product performance. So spend time distilling the problem from every angle, and share that with the entire product team. It will act as a beacon of light to follow.

Thanks to Hubert!

Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.

As always, we’d love to ask two small favors from you:

  • First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can find the podcast directly on this feed.
  • Second, please rate the podcast on iTunes or “recommend” it on your podcast app.

Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments below, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.


11
Dec 15

All The Responsibility None Of The Authority Podcast – Season 2 Is Here!

2015-10-06-14.09.42

My ATR-2100 Mic and Mac laptop – where the magic happens!

It’s been just over a year since I started All The Responsibility, None Of The Authority, the podcast for product managers, product marketers, innovators, and entrepreneurs who want to be more effective and more successful creating and selling products.

I published a total of eight podcast episodes – not terrible, considering that most podcasts end on or before their seventh episode. So I beat the point spread!

And those were pretty meaty episodes – about product management systems of record, about the business value of product management, about a new way to think about product “requirements.” But for the second year of the podcast we’ll be a little more ambitious and get a lot more content out than the first year. Of course, still with the meatiness, the immediate applicability, and the powerful new ideas. So we’ve relaunched the podcast for Season 2. I say “we” because I’m joined by a new host! Rob McGrorty, product guy at Webgility in San Francisco, and an all around cool dude.

The other big change is a new website to host the podcast, along with a new podcast feed. The first three episodes are now up on our new site, http://alltheresponsibility.com. You’re reading this because I will crosspost new episodes to this site – and this feed which you’re listening to – as well. If you’re an existing subscriber you don’t need to do anything to get the new season with me and Rob. So you can keep your subscription here, or if you like, get the new feed from alltheresponsibility.com.

As always, we have our “three things you can start doing today to put these ideas into practice.” We want to give you concrete actions you can take from each of our episodes, which is a great savings in your cognitive capacity. (We’ll be doing a podcast on cognitive capacity and its implications for product managers later in the season.)

Let’s get on with the new season! This is the short introductory episode, introducing Rob. And there are two more episodes following that, a very interesting two-part interview with someone I think is solving a very big problem for us product managers, as you’ll hear.

And since today’s episode is “introduce the new season,” and this podcast help you become a better, more effective product person, the three things are focused on making sure you get every episode, and that every episode is as full of actionable content as possible.

  1. Sign up for our mailing list on http://alltheresponsibility.com. You can also easily subscribe to the podcast at alltheresponsibility.com/itunes, which definitely will give you insights on how to be a better product manager
  2. Write us a note in the comments, a tweet (@atrnota), an email, or leave us a voice message on the website with your ideas for what we should cover and whose insights you want to hear (that is, people we can interview). Let us know, good or bad, what we’re doing right and what we’re doing wrong.
  3. Give us a rating on iTunes, tweet about the podcast, or otherwise share your thoughts and – hopefully – recommendation on this podcast with your tribe. The better everyone gets as product managers, the better off we all are.

03
Nov 15

What Does A Product Manager Do?

When someone asks you in the future “What does a product manager do?,” instead of saying “he or she is the CEO of the product,” you can say they:

  • Find a market problem (and validate it)
  • Create a solution to the problem
  • Take it to market

Wait a sec! That seems simple, almost like something my mother might understand.

Product Management Is All About The Money, Baby!

Most of you have the ambition to get big. How do you do that? The only way to get big as a product company is for people to buy your product. Preferably a lot of people, for significant amounts of money at a time. Duh!

But why would people buy your product? We know there are products that people don’t buy. We don’t want to have one of those – because you can’t get big, or even grow at all. If you look at the revenue line for a product that no one buys – it’s nasty! We don’t like that line at all!

Why Do We Get Revenue?

Compare it to our desired revenue line – up and to the right – and accelerating as it goes up. If our product sells like that, it means it’s solving an important problem for some people. Important enough that people will pay for the solution.

You may have a beautiful product, beautifully engineered and architected, and rocking in usability. But if it doesn’t solve a big market problem… Flat line.

A product can have some warts, not quite work as the user expects all the time, have some typos, use a 1998 style UI – but if it solves a big problem better than anything else… Up and to the right.

Problem Should Be At The Center

This is called, in Lean, “product/market fit,” or “finding a repeatable business model,” or other things. These terms suggest the product is at the center. But in truth the market problem should be at the center. That’s what drives your revenue up and to the right – a good market problem that only you solve, or that you solve better than anyone else.

Also Known As … Product Management

There’s a person in your company, perhaps multiple people, who are responsible for finding these problems and figuring out how to solve them. If you’re a small startup, this is going to be one of your founders. In a larger company, that person is usually called a “product manager.” (Perhaps this role should be called “problem manager?”)

The Rest Of The Story

Apart from finding (and validating) the problem, there are two other important things product managers do as well – less important in some sense (doing a better job of building a zero-revenue product still leaves you with zero) – but still necessary for success.

One of these is to guide the creation of the solution. This happens differently at different companies – sometimes the PM creates a full spec, sometimes a tweet is good enough to guide the engineering team. But it’s the responsibility of the PM to make sure that what comes out solves the market problem.

The third critical piece is to get the product to market. This is often called, surprise, “go to market.”

  • Making sure Marketing knows who to target with programs, and knows the right messages to put out
  • Giving the sales force tools for reaching those people and selling the solution effectively. (Remember, those people are anxious for a solution and willing to pay for it.)
  • Providing competitive analysis and other materials so your product prevails in sales engagements

Taking Action

Here are three things you can do today to use these ideas

  1. Start thinking of yourself as a “problem finder” – and start to learn how to find problems (hint: Here are some posts on this blog to help you get started: Finding and Validating A Market Problem, How Badass Are You At Finding And Validating Market Problems?)
  2. Make sure you can articulate the problem your product solves for your market segment. (Here are some guidelines on how to do that effectively: A Weak Value Proposition Is A Symptom, Not A Disease, Do You Want To Be A Badass Product Manager?)
  3. Make sure your marketing and sales people understand who you’re selling to and why they should buy your product and not spend their money elsewhere. (What Is Marketing, To Product Managers?)

Summary

Product management consists of three main activities:

  1. Finding and validating market problems
  2. Creating solutions to those problems that are better than other alternatives
  3. Taking those solutions to market

While #2 is the most natural, for a lot of us, #1 is far more important. No matter how good your product is, if it doesn’t solve an important customer problem, it won’t sell. And if the market doesn’t hear about it, or hears the wrong thing (#3) then they won’t buy it either.


29
Oct 15

What Is Marketing, To Product Managers?

Quick take:

  • Marketing, the department, is about executing the programs that deliver leads and establish brands.
  • Product management, the department or function, is responsible for providing Marketing with the value proposition, the positioning, the segments to attack, and benefit/feature stories they and Sales use as the basis for those marketing programs and for individual sales engagements.

You can’t let Marketing develop the value proposition. In fact, you’d better know it before you even start building the solution, because you understand the problem you’ve solving, the segment who has that problem, and why they will buy your solution instead of doing something else with their money (the three components of a value proposition). Marketing can help refine it and articulate it, but it’s not their job to come up with it.

So, if there’s no Marketing department, guess what? You get to do the execution. If there is a Marketing department, guess what? You still have to come up with the value proposition, the segmentation, the competitive differentiation, and the benefits/features.

Thoughts? Is this how you do it?


28
Oct 15

How To Share A Roadmap Without Driving Into A Ditch

A winding road (CC BY-NC-ND 2.0
Massimo Marino)

Roadmap-related conversations exploded on various social media channels a few weeks ago. Jared Spool put up a post on Medium about a concept he learned from Bruce McCarthy – basing roadmaps on themes rather than features. (Although product managers have known this concept for a long time.) And Marty Cagan responded to the Jared Spool post with one of his own. Of course, product managers have written about roadmaps – and been on the ground making roadmaps – for a long time.

But a question on the PMHQ Slack channel piqued my interest most particularly. Someone asked: “What do you use for roadmapping?” The questioner turned out to be someone from outside the high tech/software space. She wondered how we managed our roadmaps in high tech and software.

I used the question as the springboard for a riff on the PM HQ chat board.

My attitude toward “roadmaps” and “roadmapping” for products is perhaps iconoclastic. And apparently idiosyncratic. But I hope the following practical advice will help you navigate the quicksand of roadmaps. Especially when you have to share with people external to the product organization.

What Is A Roadmap?

A common question when PMs get together is “what do you use for roadmapping?” This question can mean lots of things, but usually it means one of two:

  1. How do you manage the list of features that you expect your developers to work on over the next period?
  2. How do you present the list of features you are developing to outside stakeholders? Such as executives, other internal organizations, customers, or analysts.

Personally, I usually call #1 “the plan” rather than the roadmap.

If I’m going to share a roadmap with anyone other than dev, I make it in PowerPoint. I never want to put a) real or b) all the information in something I’m sharing externally. Not even to other people in the company, normally.

By “real” I mean “with all warts exposed.” For example, our internal plans use insider technical terms. Those depend on understanding our technology (not just the product). I don’t want to require or expect my stakeholders to make that leap.

I always sanitize what gets shared with others. And then I also move it “up a level” – or four.

When presenting a roadmap externally, I always show themes or “epics,” rather than features. I often present them as happening over a time period different from their actual schedule. If there interesting interim releases, I might show those as well.

There are quite a few constraints when putting these epics onto the roadmap. Usually I want them to be one or two words, maybe three. They need to be in non-technical language, and not domain specific. Often one box or epic on the roadmap will represent many “epics” or “features” or “chunks of value.” In our real plan, they are on their own schedules. Sometimes I separate out features that are part of the same epic because they help me tell a better story. For example, if I’m presenting to a customer who requested a specific feature, I might highlight it.

And if possible I don’t even give people that roadmap, the cleaned up one, I only present it to them. (This is often not possible.)

For example, my team’s current feature is “Staffing Requests Phase 4 – Replan/Route-To enhancements.” It’s an epic. But while it’s a meaningful name for the product org, it’s a terrible name to expose to outsiders. It would raise many more questions than it answered. So, for a customer, it’s called “Resource Management” or “Centralized Staffing.” And as such it’s combined with some other related epics that I also don’t mention. This combination of epics is a theme.

I also often will prune things off the roadmap for particular audiences. For example, if I know they don’t want some capability, I might not mention it. Or if I’m worried they’ll think it’s distracting us from their favorite thing. Or, to emphasize they are not our only customer, I might highlight a feature they don’t care about.

Roadmap Tools

There are many tools that position themselves as “roadmap tools” for product managers. Usually these are really about the first meaning I listed above – “the plan.” They aren’t oriented to “how do I present what I’m working on to stakeholders.”

In my ideal product management tool, I could make a roadmap I could actually share with stakeholders. It would start by supporting “public names” for features and themes. It would have the ability to buffer the expected delivery dates. I could edit, annotate, or hide any entries I wished. And it would put all that into a PowerPoint slide that I could load into a deck and update in real time. This is not a trivial set of things to support.

Software Is Different

The original question was from a software industry outsider. I thought it would be useful to compare software roadmaps with those of other industries. The first takeaway? Comparing a software company’s roadmap to a roadmap from another industry is apples to oranges.

Usually those other types of companies have products that obey the laws of physics, such as semiconductor makers or car manufacturers.

Conversely, software company roadmaps often present capabilities that are not even designed, much less built.

Here’s a thought experiment for you. How soon before they hit the showroom do carmakers release information about the features and capabilities of their next car models? It’s about a year if you think about it. How long does it take to get a new car feature that’s designed and developed for manufacturing to the showroom floor? The answer: about a year. When carmakers announce new features on cars, what they call their roadmap, they’ve already done all the design and development work on those features. They are not predicting the future.

How about semiconductors? Intel has a 1-2 year roadmap for its processors. How long does it take for a new semiconductor fabrication innovation to get from discovery and validation in the lab to being an actual feature on a chip that you can buy? Well, it’s about three years. Intel’s two-year roadmap is not predicting the future – they know and have proven the technology.

And even then the roadmap slips. Back in May of 2015, Intel said it would ship 10nm chips in calendar 2015. By July its roadmap had changed, with the 10nm chips pushed back to 2016.

Take action

Here are three things you can do today to improve the roadmaps you share with external people.

  1. Focus your roadmap on themes, not features.
  2. Use customer language in your roadmap, not technical or insider jargon.
  3. Make sure you understand the desires, needs, requests, and pains of the stakeholders to whom you are presenting, so you can fit your presentation to their expectations.

How do you use roadmaps?

Do you have techniques for sharing the future for your external stakeholders? Do you have stories about how you finessed a difficult situation? Or have you accidentally set their expectations that you would deliver something impossible?