Building a great product is hard. Building a great product without a plan that accounts for iteration, quality control and user feedback is nearly impossible.
That’s where a well crafted product roadmap comes in, something Janna Bastow knows all about. A product manager by trade, Janna co-founded ProdPad because she simply didn’t have the proper tools to plan and manage her own roadmap and product backlog.
She’s also a co-founder of Mind the Product, the premier global community and conference for people who live and breathe product. And in what free time she has left, Janna mentors other startups on how to build and grow responsibly.
I hosted Janna on our podcast to discuss how product roadmaps must evolve at scale, exercises for prioritizing what you build and why every product manager must be able to say ‘No’. If you like what you hear, check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed.
What follows is a lightly edited transcript of the interview, but if you’re short on time, here are five key takeaways:
A proper product roadmap is approached from two angles: It solves big objectives and builds toward your company vision, and it’s flexible enough to accommodate changes in the marketplace.
Inviting stakeholders from across your company into the discussion of what to build helps you analyze tradeoffs and requirements. To do this, Janna recommends an exercise called The Product Tree.
Avoid aligning your roadmap to specific dates; instead, split your roadmap between shorter windows and longer time horizons, which allow for flexibility.
As your product grows, you’ll need to move away from a to-do list of features and organize your roadmap by the problems that you’re solving.
If a feature request isn’t aligned with a company’s product vision and objectives, it’s paramount that product managers say no – even to their boss. Tests and data are a PM’s greatest ally here.
Adam Risman: Janna, great to have you here. Product management is a very young field compared to the likes of design and engineering – and one that people come into from a variety of paths. What was yours?
Janna Bastow: When I first started in product management I’d actually never heard the term. I was a customer support rep for a tech company, and they liked the way that I was able to report bugs and talk to the customers. My boss pulled me aside one day and said, “I’d like to make you a junior product manager.” My first reaction was, great, I like it. What is it? I actually had to Google it and figure out what my path was going to be and how I was going to figure out this new role. Having studied business and dabbled in tech and in design beforehand, I’d never actually heard of the term product management. That’s changing nowadays.
Adam: When you’re consulting with startups about product management, you always begin the projects with is a simple question: What problem are you solving with your product? What were the problems you encountered that led to the creation of ProdPad and Mind the Product?
Janna: Two distinctly different problems. One was that I was a product manager and I wanted to learn from other product managers and there simply wasn’t a lot of resources online. There certainly weren’t a lot of product managers in my network. A couple of us decided to get a few people together in a room with some beers and start holding events for product managers. It started off as a product tank, which was maybe 20 people, and that’s just grown and grown to Mind the Product over time.
With ProdPad, I was a product manager and realized I didn’t have the tools I needed to do my job. I was hacking apart Powerpoint, spreadsheets and whatever tools I could get my hands on. My co-founder and I ended up building ProdPad, which was originally just a hack project and something to help us do our own jobs. It was only a couple of years later that we realized it was actually worth getting out there to other product managers.
Where product roadmaps come from
Adam: One thing that ProdPad helps with is constructing product roadmaps. Every company needs a plan for what they’re going to build, but there are so many different ways to go about creating one. What inputs are you using for the product roadmap at ProdPad?
Janna: A good roadmap is approached from two angles. You’ve got the top-down approach, which is outlining your vision, your objectives and the big steps you need to take to meet that vision. You can’t just do top-down product management, because that means that you’re not paying attention to what’s happening in the market.
What feedback is coming in from your customers?
You need to blend it with the bottom-up approach, which is looking for all the opportunities out there: Which ideas are being surfaced by your team? What feedback is coming in from your customers? What are you learning as you’re watching the markets or from new customers? By blending these two together you can actually create a roadmap that is flexible enough to allow you to change to what’s happening in the market while still making sure that you’re building towards your vision and solving the big objectives that are important to your company.
Adam: Are any of those inputs harder to manage or balance?
Janna: The part that most product managers struggle with is the influx of ideas and feedback from customers. It’s not easy to gather everything in one place, close the loop on it and make sure what you’re building is actually still relevant to customers – even though you first heard about it six months ago. It’s this constant cycle of checking back and validating what you’re doing, even if it is something that you’ve been validating over time. You still need to make sure it’s the right thing to build as it goes out the door.
Building your Product Tree
Adam: When it comes to prioritizing what to build, you use an interactive exercise called the Product Tree Game. What’s the process there? How does the exercise work?
Janna: The Product Tree Game is partly influenced by the folks behind innovation games. It’s a great exercise. You can play with your team, different stakeholders within the company or even customers. You get your team together – different points of view, somebody from sales, somebody from support, somebody from development – and put them in a room and draw a massive tree on the whiteboard.
The trunk represents the core features – the absolute must-haves and what you have in place today. The branches represent different areas that you can go into, and the roots represent the infrastructure that’s needed to build the tree. Get everyone to brainstorm and get everything down on Post-It Notes. Then together have everyone stick them onto the tree and negotiate with each other as to where these particular features or ideas might go.
Some stuff might be absolutely core and need to be right down by the core of the branch. These are the things that need to be built first. Other things might be a lot more nebulous or blue sky thinking, which might sit out in the further reaches of the branches. The infrastructure is also really important to have there, the roots, because this is where the developers get to have a say in what’s going on. You might have a salesperson who says it would be really great if we could get this view of our users. The developer now has the chance to stand up and say, “If we want to do that then we’re going to have to build out this piece to hold the tree up,” and start explaining why you need a good infrastructure.
What you end up with is a picture of a tree, your product tree, and you can see right away looking at it whether or not it’s balanced. Did everyone decide to go in one particular direction? Is that the right direction for the company or is that not quite in line with the vision? Do you have enough things in the infrastructure to support the bulk of new functionality that’s requested? It’s a good visual way to get people involved, see how many other things are happening at any point in time, weigh in on that and feel like they’ve got input that’s going into the roadmap.
Adam: How often would a team want to complete an exercise like this?
Janna: Probably no more than every six months. I certainly wouldn’t recommend rethinking your entire roadmap any more than that. If you’re updating a roadmap more than every couple months then you’re probably changing your vision too much. Obviously smaller tweaks (are fine), but I wouldn’t recommend revamping it. That would throw off everybody in the team and wouldn’t really allow people understand where it is you’re trying to go.
Adam: There’s going to be a lot on that tree that needs to be pared down after this exercise is complete. Who should actually have a role in putting these concepts back into the roadmap, and who should have access to that roadmap once it’s completed?
Janna: The product manager themselves should own the roadmap. It shouldn’t be something that other people can stick things into or change on the product person. They should own the roadmap, but they should also do it with a good dose of transparency and understanding that it’s being built based on the input of all these people. It’s not just the product person saying, “This is where we’re going because I said so.”
You should be showing your internal team the whole roadmap.
You should be showing your internal team the whole roadmap. Everything the product manager knows about what’s coming up should be visible to people who are going to be building or supporting this thing in the coming months. When it comes to showing a version of the roadmap off to your bosses or your board or your customers you might want to pair things down. Sometimes it’s because you don’t want it to be leaked to your competitors, because you’ve got something really secret coming up. It might be because some things are just mundane and aren’t interesting to your customers or to the board. There’s nothing wrong with having a slightly different version of the roadmap that you show internally versus externally, as long as they more or less tell the same story.
Assign timeframes, not dates
Adam: One thing you won’t see on your roadmaps is specific deadline dates. You’ve said product manager said focus on broader windows instead. Why is this so important?
Janna: It separates out the deliverables that are happening in your release plan. The things that are being immediately built out. We do build to dates but we only build out two to four weeks out, a couple sprints, and anything beyond that we’re actually open to change based on feedback that we’re hearing. New things we’ve learned based on what the competitors are doing, what the market’s doing, what our customers are asking for. It actually allows us to be more flexible and change based on what we’re seeing happening in the market.
Adam: We’ve written a lot about our roadmap structure, and we look at six weeks and six years out. What are your organizational principles?
Janna: We build in terms of current, near-term and future. Generally speaking we’d be looking at something like two months, six months and beyond. It’s not actually that far off from the Intercom way of looking at it. We’ve heard of other ones that are now, next and future, or 333 type formats. It’s whatever works best for the company.
One thing that happens with roadmaps is that people tend to think about them in terms of calendar years. They look at it and say, “This is what we can do in the year,” and cut it off beyond that. In reality a much smaller company with a less mature product might only really have visibility, and need to have visibility, of the next three to six months. They don’t have funding beyond that. They don’t have customers yet. Whereas a much more mature company might think two to five to ten years beyond where the roadmap begins.
The length of the roadmap should be dependent on the product itself and the maturity of the company. But the split of proportionally shorter time versus longer and longer time horizons makes a lot of sense.
Adam: When you look at the short-term deliverables it’s obviously much easier to monitor progress and know what deliverables are realistic. When it comes to those big-picture goals several years down the line, how often should you be revisiting or updating those?
Janna: The longer-term stuff should be revisited if you’ve change your fundamental vision. It’s something that needs to happen at a company level. Is there still a market for what they envision they’d be three years down the line? Are they still in the right place?
Usually as companies progress, if they’re successful, they actually open up the ability to think further into the future, which allows them to have a broader vision to change what it is they were originally going for and bite off bigger pieces. It’s natural that any company will revisit their vision and therefore their roadmap maybe every year or so.
Measuring success
Adam: As someone who works with a lot of startups on roadmaps, is there anything you frequently spot that folks should avoid?
Janna: The trap I see product managers falling or small companies falling into is creating a roadmap that’s made up completely of different features. When you’re very young and you’ve just got this MVP out there and a handful of customers giving you feedback there’s actually nothing wrong with having a small set of features that are being built next. But as you go it becomes overwhelming to look at a roadmap that’s a whole pile of features, and you’ll need to start grouping them into themes around the kinds of problems you’re solving.
If you’re building an MVP you might just these are the next 10 things to do, but as you start building out a bigger roadmap you need to communicate a bigger story than just, “We’re going to launch these features and see what happens.”
Adam: One reason people might fall victim to that feature list or a tendency to include dates on a roadmap is it serves as a checklist for showing success. With those things removed how should product managers measure their success and communicate it to leadership?
Janna: Product managers are notoriously hard to measure. It’s easy enough to measure the success of a product. You’ve got metrics and objectives that product showed hit – particular conversion, revenue or growth targets.
Product Managers sit in the middle and don’t necessarily have easy things to track. Unlike a development team they’re not tracked by number of tickets they complete or number of hours done. Unlike salespeople they don’t have direct sales quota. Unlike support they don’t have customer success metrics. The product manager is often judged by a mixture of these things, as well as how they’re actually working in the team. This might come out at 360-degree reviews or other tools like that.
Learning how to say ‘No’
Adam: There’s a great blog post you wrote, “Is your boss hijacking your roadmap?”. We talk a lot about how product managers must be able to say no to requests. How exactly should they go about saying no to the boss?
Janna: There are two major things that a product manager will on a regular basis have to say no to their boss about. One is saying no to giving dates. Short term it’s expected that you’re going to give a range for that date and be able to that this is coming out within a month or so. That’s based on your team being able to provide you with some insight as to what’s happening. Long term though it’s worth pointing out that things like resources aren’t known. Therefore neither are dates.
You can turn back to your boss and say, “You’re asking me for a date on something that’s a year and a half from now. We don’t know how big the team is going to be. We don’t know whether we’re going to get that funding or hire the right people. How can I possibly give a specific date on this?” That usually helps point out where there’s going to be deficiencies in giving any sort of date on a future deliverables.
If you feel it’s not aligned then question it.
The other thing you might have to say no to quite often is features. It’s important to use things like the product vision and objectives to point out whether something’s aligned or not. If you feel it’s not aligned then question it. Ask why they think something is important. You might actually figure out that your HiPPO (highest paid person’s opinion) has a different vision than you, in which case it’s a more fundamental problem than just that one particular feature.
You can also use tests and data to your advantage. If you’re just bringing in your opinion versus the HiPPO, you’re going to lose. If you’re able to test and prove whether something’s going to work or not, or move the needle in the way they expect it to, then you can do that before you commit to building something absolutely huge.
Adam: Whether it be from an organizational leader or a customer, when do you actually find yourself at ProdPad saying yes to a feature request? What has to align?
Janna: At the very least this would be something that I’d expect more than one user has been asking for and is something that fits with our vision. It makes sense in the broader scheme of things with what we’ve been looking at. There’s also a little bit of gut feel in there. We’ll talk to a customer and find out what it is they’re trying to do and try to empathize and ask, “Is this something that we also feel would be useful to ourselves or to other customers? Is this something we feel should actually fit in with something else we’re working on?”
It opens up a lot of other conversations. As soon as we hear something new from one customer we’ll turn to other ones and ask if it’s a similar problem. Find out if it’s something that has been irking other people but we possibly didn’t hear about before. Often you’ll find that if one customer’s asking for something it might match with other people and therefore deserves to find a place in the roadmap somewhere.
ProdPad, Mind the Product and beyond
Adam: You just shipped a new version of ProdPad. How did you know it was time to look at building a whole new release rather than releasing a lot of these improvements incrementally?
Janna: Incremental feature releases are great if you’re testing if something is worthwhile even building. At this point in time we’ve proven ProdPad. We have more than 600 customers and incrementally it’s very difficult to improve things like making an app more stable or faster. We realized the tech behind it was at its upper limits and the best way to allow us to move it forward and create platform that we could continue iterating on was to build the front-end again.
A new version of ProdPad, management software for product teams, was released in early 2017.
The new release is actually a rebuild of the entire front-end, but we also took the opportunity to rethink quite vastly how our navigation works. Along the way we actually got in quite a few changes to the usability to make it easier to navigate, easier on the eyes, and also blindingly fast and more stable than the previous version ever could have been.
Adam: You and your colleagues at ProdPad have shipped more than just the app itself. You actually shipped a book a few years ago, The Handy Guide for Product People. Obviously it’s still relevant – you had copies on hand at SaaStr 2017 – but if you released a second edition of that book today, what would you add to the mix or give greater emphasis?
Janna: Over the years I’m hearing more and more product managers struggle with stakeholder management or objection handling. Figuring out how to say no, how to influence people within their team even – though they don’t necessarily have any authority per say over other folks. I’d add more information around stakeholder management or simple objection handling for our product managers. How to say no. How to influence people without necessarily having them report directly to you. How to manage your time and your resources as a product person.
Adam: As someone who runs the premier global community for product managers, Mind the Product, you’re exposed to a lot of new voices and thinking in the field. Whose ideas have caught your eye lately, who our listeners should pay attention to or try to see speak?
Janna: As product management evolves we’re actually seeing a lot more emphasis on the art of leading in product management – the people management aspect of it and the idea of having a team of product people delivering. One to watch is Nate Walkingshaw. He’s the CXO of Pluralsight. He’s actually writing a book on product leadership alongside Martin Eriksson, who’s my co-founder at Mind the Product. Nate’s speaking at Mind the Product SF, which is coming up in June.
Adam: You tweeted that recently you found yourself debating over brunch the impact AI might have on product management in the future. More generally, how do you see the field evolving in the next few years?
Janna: That’s a really great question. The brunch conversation was talking about what sort of changes would have to happen in artificial intelligence to replace product managers. The debate asked whether it’s an inherently creative field that will always require a human touch or whether it’s something that could theoretically be replaced by the robots. We never actually came up with an answer, but I think over time we’re going to see a lot of the grunt work of product management being replaced. A lot of times product managers are spending their time simply spec’ing out or devising experiments for the same things that product managers before them have always done. There are way more tools available to product people and product teams available now that help them focus more on asking the bigger questions and solving real problems, rather than simply just writing specs all day.
Adam: Janna Bastow, we’ll leave it there and hope to catch you at Mind the Product in San Francisco on June 13th and in London on September 8th. Thanks for joining us.
Janna: Thank you very much.
The post Mind the Product’s Janna Bastow on building product roadmaps appeared first on Inside Intercom.