Steps to take when creating a roadmap at your new job

1. Check pre-existing assumptions

So you just started a new job. Oftentimes, most of the time you’re adopting somebody else’s roadmap, which will be full of assumptions made by the PM and/or the team at large. Your first task is to check these assumptions and find out what they mean.

How to check assumptions in the roadmap

Have lots of conversations! Chat with everyone around you, especially all the key players, and get their read on what the roadmap is, learn who’s had eyes on it thus far, and try to understand why they think certain things are on there.

You want to understand their understanding of the roadmap.

You also want to understand their understanding of the problems that need to be solved.

The key here is to not make assumptions about the roadmap yourself! Those assumptions have already been made. You want to find out why they’ve been made before you start making your own and tearing plans apart.

2. Find space to restart the roadmap

Restarting and creating a roadmap from a blank slate is a great tactic if the one you’re working with is chock-full of assumptions, junk, or no one agrees on it. Start fresh with new things you’re learning! But do so gently.

As for how to do this, check out some tips on how to admit roadmap bankruptcy.

You might need to help your new company break up with timelines and Gantt charts. A great justification for restarting the roadmap is to move away from using deadlines and due dates.

You can explain that the old roadmap is more of a “project plan” – and that the new document is a real strategic roadmap. (You can reassure them that you’ll still need project plans!)

3. Rebuild the product roadmap

All of your conversations, other research, and what you’ve learned about the company objectives should help you identify what the real problems are that need to be solved. Now you start organizing them into a product roadmap everybody understands.

Rebuilding this product roadmap means establishing some other things within the team:

• Choose a prioritization model that suits your product and your team
• Choose a product backlog framework for all the items that don’t make it onto the roadmap
• Establish good backlog grooming practices to keep it organized!

Note: Don’t worry about leaving stuff off. People will probably notice something is missing and speak up. This gives you insight as to what’s really important. If something is that important, it will pop up again as a problem that you need to tackle.

4. Keep iterating and create buy-in

The new version of the roadmap you create should reflect the up-to-date understanding of the problems and the opportunities and the challenges ahead of you, and therefore should represent an up-to-date version of your product strategy.

The only way to get there is if you continuously have conversations with the different stakeholders and loop them in. The new roadmap might resonate with them immediately, but it probably won’t.

Think of this as your first draft of a prototype. It’s going to be a bit junk and people might have criticism. That’s good! Because what you’re actually doing is checking whether you’re on the right path or not. Get their feedback on the roadmap so far and keep iterating.

How to create buy-in for creating a roadmap

If you continuously have these conversations, you’ll help the team come around to the fact that they’re wasting less resources by not building the things that they thought were a good idea a year ago when they set the old roadmap. They’ll realize you’re actually preventing them from building stuff they didn’t want in the first place.

The other bonus is that when you present it back to people, they will feel as if this roadmap is theirs. And it is! Creating a product roadmap is a collaborative process.

5. Re-introduce the roadmap

I’m not a fan of big reveals. Not only is there emotional tension built up around it, but also when multiple stakeholders are in the same space, you often stifle honest feedback. Outliers might not want to speak up in front of everyone, while other people might succumb to groupthink.

Plus, big reveals falsely give the impression that this roadmap is “your thing” that you’re presenting with full ownership.

Instead, keep it casual. You can even do several small reveals to smaller groups and some key individuals.

How to introduce the new roadmap

If you followed Step 4, this should actually be easy. When you’re ready to release the “official” new roadmap, everyone’s already seen it and feels invested. They know they helped with it, and again, it feels like it’s theirs.

You can say, “I’ve had all these conversations, and I understand that the problems to solve are X, Y, and Z. Based on what everyone has said, I think this is our roadmap.” Let them know it’s a first iteration, it can be added to and shaped, and that time estimates are never set in stone. 

As you start using the new roadmap

Switch to a lean way of working. As the team finishes these projects, remind them that you won’t rush ahead to the next item on a list. Instead, you step back and revalidate the most pressing problem and the next best thing to build.

You can also begin looking at success.

Last word on creating a roadmap at your new job

Your job is not to create a new roadmap for a company by scrapping what they had before. That’s obnoxious and just bad product management.

PMs don’t have answers, we ask questions. We facilitate conversations, and we learn from them and reflect it back to them. We help the team find compromise, and then present the story that makes the most sense.

The post A New Job Means Creating a Roadmap 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.

I’ll be honest with you: this is not a good practice. (In fact, it’s #5 on my list of roadmap things to avoid.)

The roadmap is not a list of things that you will do. It’s a list of things that you could do.

More than anything, it’s an experimentation tool – a place to lay out the solutions that you can test, in order to address the most important problems facing your company.

Once you’ve identified the main problems according to the business’ OKRs, then you brainstorm potential solutions. There are usually many, varied paths toward your goal. Each problem could have 5 to 10 potential solutions attached to it. Narrowing them down and selecting the best one requires experimentation.

The product roadmap records what these experiments are, how they’re going, and what’s been learned.

All of your ideas are hypotheses

All of your ideas are hypotheses, and as a PM, your job is actually to invalidate most of them! That said, product ideas don’t pop out of the blue, and your hypotheses aren’t created in a vacuum.

Product ideas are derived from OKRs, top-level objectives that are defined by the business. The product team sets out to solve a problem around churn, retention, revenue, etc. For example, as a PM you can say, “Okay, the problem we’re tackling this month is — we need to get conversion rates up, and the issue is around our sign-in flow area. We need to move people into the purchase flow. How can we do that?”

From there, you might brainstorm three to ten different ideas or potential solutions. Some will succeed and some will fail – that’s a fact. But you don’t know which ones until you test them. And to test them effectively, you need hypotheses.

How to phrase a product hypothesis: If we [try this idea], it could solve [this problem] and it could uplift [this metric] by [N].

Cool, that’s the experiment to run! Then you see how the new feature performs and take steps from there. But while we’re here, a quick note about new features…

What counts as a potential solution? Think wider.

Product solutions aren’t necessarily new features. What about changing a feature – or even removing a feature? Either of these might improve usability or impact other metrics and objectives that you’re working toward.

Some solutions might not involve code at all! The trick could be changing the price or the packaging or the value proposition. Shift how you talk about a benefit on the homepage or rethink how you present certain information to the customer. Adjustments like these can transform the way people interact with your product – which, in turn, could solve some of the problems on your product roadmap.

The point is: experimentation doesn’t always require the development team. Instead, it might require marketing, sales, customer success, and support. PMs should take a step back and think more holistically about what it is they’re actually solving so that the rest of the team can be involved as well.

What counts as a product roadmap experiment? Think leaner.

Again, by “experiment” I don’t necessarily mean build full-on code. Experiments can also be fast litmus tests to check what’s viable or not before devoting any real resources to it. There are many ways to do customer decision discovery, do quick prototypes, and put in place little tests. It could even be a prototype on paper that you test with select customers. 

As you do these tests, you identify the experiment options that you think are going to be easy, the low-effort, high-impact ones, and float those to the top. Work through the list and see how close you come to solving the problem. 80% is close enough. Move on.

Most importantly, record everything.

The product roadmap is a record of learning

As a product team, one of the most important things you can do is log your decisions – for future you and future team members who join. This starts with each of your tests.

Logging experiments in the roadmap

You can use the product roadmap to display how you’re actually progressing with experiments, such as:

• This one is something that we’re still discovering. 
• This one shows promise, and we’re going to do some design prototyping. 
• This one failed.
• This one was successful.

But for any idea that you have, which is to say any experiment that you’ll run, you should also log your target outcomes along with the actual results. This is crucial for understanding the solution’s viability at the moment, and it also helps prevent repeating any work (or mistakes) down the line.

Let’s say there’s a delta between expected and actual outcomes, such as, “We thought Idea X would get us 100 new users each month, but it actually only brought in 20.” Well, obviously you won’t move forward with Idea X right now. And this result is recorded in case the idea comes up again.

How to preserve what you’ve learned

ProdPad is basically a log of all the decisions made and all the lessons learned over time. In addition to your working product roadmap, which is in the Now-Next-Later format, you also have a “completed roadmap.” Any initiatives that you’ve completed are shown, in reverse chronological order, with all the experiments that were attached and how well you did with them.

After all, a product manager’s impact isn’t just features that they’ve built. It’s also the problems they’ve tried to solve and the experiments they’ve tried to run, whether they worked or not. Designers have Behance, developers have Github. What do PMs have? That’s one reason we created Prodpad.

Set the stage for product roadmap experimentation in your team

Want to encourage this approach among your colleagues? Shifting to experimentation mode requires changing the language that you use. Here are a couple of ways to help your team embrace experimentation:

1. Continuously reframe conversations that become too feature-focused or committed to one solution. An excellent reframe is to ask: “What problem are we trying to solve?”

Ask these sorts of questions and give them time to think things through. Give them space to talk through how they might solve a problem. This requires vulnerability and some psychological safety among the team, so they can let go of needing to be right. This brings us to…

2. Talk about ideas as “hypotheses” or even “bets.” This invites people to get into that scientific, almost playful mindset.

Failed hypotheses and lost bets don’t really exist in product management, because you’re always learning something from the experiment. Besides, you aren’t trying to prove your idea right. You don’t have the answer, and no one does! You’re trying to find answers as a team.

The post Your Product Roadmap is a Tool for Experimenting appeared first on ProdPad.

Product roadmaps vs release plans: the difference

When comparing product roadmaps vs release plans, you need to understand that the roadmap and the release plan are two different tools, one used after the other. The first is exploratory and informative (strategy), the second is practical and applicable (execution).

A product roadmap shows what is coming up (Now, Next and Later) and what is being worked on at this moment. This allows teams other than product and engineering to see what’s coming down the pipeline and plan their own work as needed.

The release plan is about coordinating the launch of what’s already been built, particularly with the efforts of other teams in relation to the launch. This includes marketing campaigns, sales campaigns, closing the customer loop, measuring the success of the release, etc. All of these activities are put on a timeline.

The roadmap gives the whole company visibility of what is coming up without causing problems by tying things to a date. The release plan takes over when development is done and coordinates the wider team’s activities to make all major releases a success.

The confusion between product roadmaps vs release plans

This transition from roadmap to release plan is where the worlds of product management and product development can get a little murky. In many organizations, they’ve started to merge or overlap. Indeed, this is how so-called “timeline roadmaps” have come to be a common practice.

Maybe some teams think they’re being efficient by doing both in one go, in one discussion, in one tool. But actually, you’re doing a disservice to yourself, your company, and your customers.

Great product management isn’t possible when it’s tied to timelines. And great release planning is about so much more than the product launch itself. By separating these two processes, you’ll build a better product and deliver that product more successfully. 

The downsides of a timeline roadmap

If you’re using a timeline roadmap you are basically using a glorified release plan to manage your product strategy. You’re mixing up in the differences between product roadmaps vs release plans and combining two distinct processes that are each critical to your company’s success.

Here are three reasons why this mix-up is a problem.

Timeline roadmaps are more about development than they are about product discovery, strategy, or your product vision. The team’s focus moves from the problems you’re trying to solve — to the features you’ve plucked from the backlog and decided to build.

Taking a step back to look at the problems facing your business and users as well as your common goals is what keeps your roadmap fresh and adaptive to change. These changes could be in the market (you have a new competitor) or new insights about how your customers use your product.

But when you’re running a feature-focused timeline roadmap, you’re less agile across the board.

With timeline roadmaps, some teams plan for a whole year in advance (or even longer), which doesn’t make sense! Why would you tie your own hands? When you make promises to senior stakeholders and customers, you lose the ability to change direction and pivot your strategic goals. People expect you to hit X target by Z date. Perhaps you can change direction after what you’ve committed, but not before. And then it might be too late.

Bottom line: long-term product commitments can mean building the wrong things and missing the right opportunities.

When timeline commitments absolutely must be changed, this can be a huge burden for PMs on a psychological level. Stakeholders don’t want the dates changed. So then it’s your job to get them to agree to the changes and accept that these changes are worthwhile, maintaining their trust in the process.

This requires too much time and effort on your part. And if it happens repeatedly, resentment can build up between teams.

The benefits of a horizon roadmap and separate release planning

There’s a better way than using a timeline. Horizon roadmap is about the problem you’re solving. At Prodpad we advocate for horizon or lean roadmaps. Here’s why:

When you’re focused on problems that need solving, you allow for continuous discovery and experimentation. Your vision for potential solutions is much wider, so you generate more of them, and they’re more creative than if you’d stayed in the box of your backlog or timeline.

Ultimately you find the best fit for your product and your company objectives. 

The release plan is shorter, perhaps covering just the next two cycles of upcoming releases rather than the next 12 months. With this closer focus comes a smaller level of granularity — you understand the details of what needs to be done, how long it will take, and when it will be ready.

With the lean roadmap, it’s much clearer what is currently being worked on and when it will be delivered thanks to it’s visual representation.

You can finally make realistic promises to the rest of the company! With a transparent and reliable product pipeline, other teams will feel more confident in their own work, campaigns, and aligned efforts. This of course ripples out to executives, customers, and other stakeholders. Less friction, higher morale.

How to separate your product roadmap and release planning

If you’re ready to stop the fight between product roadmaps vs release plans, and instead want them to work in harmony you need to first separate your product strategy from your development timeline, here are a few steps on how to do it.

1. Recenter the problems you’re solving in each cycle. Make them explicit! And tie each delivery or feature idea back to a problem or one of many user stories. For more on this, check out Janna’s thoughts on product prioritization models and how to prioritize on a “Problem Level.”
2. Shorten your timeline. Look at the current development cycle and the next one only. Don’t look six months down the road, and don’t make commitments into the future! If you’re pressured to provide time estimates, pull back on precision (no exact dates) and emphasize the new problem-focused approach.
3. Separate discussions and hold separate meetings. This could help the team adjust to thinking about roadmap strategy and release planning separately. There would be one meeting for product strategy and prioritization discussions, and another for committing development resources and timeline planning. To define a release planning process for your team, check out how to master release planning.

The post Product Roadmaps vs Release Plans: Understanding the Difference appeared first on ProdPad.

Instead, I’d be proud if your first roadmap looked something like this:

Why? Because a roadmap is a prototype for your product strategy.

As simple as you can articulate and test. And in the case of a product strategy, that’s usually outlining some key problem areas or opportunities you think are noteworthy, and laying them out in the order you think they should be tackled.

That’s your first roadmap.

Is that what you’re going to go DO and build now? Oh hell, no! That would be incredibly presumptuous. On par with taking your back-of-napkin sketch of an untested idea and ordering a developer to go build it. 

Your first roadmap is just the beginning

That first product roadmap is a starting point for learning. Now that you’ve laid out your assumptions, you’ve got a handy way to check them with other stakeholders and see what holds water or not. 

And your first roadmap is going to be imperfect. Your stakeholders are going to pick holes in it. Product managers need to have thick skin for exactly this reason. You’re not here to be right. You’re here to facilitate the discussions to get us all to better.

Over time, and over the course of lots of useful and enlightening discussions, you’ll start to unpick what the real problems and opportunities are, and what order your team can tackle them in to be most likely to achieve your objectives and reach your ultimate vision. Over time, you’ll iterate on your roadmap, and move from the hot mess you started with, to a cohesive strategic plan.

It’ll become more granular and useful to a wider range of stakeholders. It’ll be more robust, as more and more eyes and brains from around the organization sense-check it. And It’ll look more like the roadmaps we showed you in your ProdPad demo when you first got on board. 

It’ll never be 100% perfect though. That’s a bit of control that we’ve all just got to let go of. After all, we don’t have perfect information, so we can’t craft a perfect plan. 

It starts with picking the right format!

Our go-to here at ProdPad is the Now-Next-Later roadmap format because it has that sense of imperfect information built right in: You’ve got higher granularity of information about things right in front of you, and less for things further and further out on the horizon. 

Your roadmap is meant to have this flexibility built in so that as you learn, you adapt. Your roadmap flexes and is updated based on new information, and so what was considered the best roadmap for the information of the time is set aside to make way for a constantly iterated version of that roadmap, always showing the best version for the information at hand. 

So always remember: Your first roadmap is not going to be perfect. Far from it! Embrace the fluidity of the imperfect assumptions, nowhere near set in stone. 

Your final roadmap won’t be perfect either. It’ll just be the best representation of what you know at the time, which should be informed by all the insights and inputs you have access to as a well-connected product manager. 

Let go of perfect. Get roadmapping instead. 

The post Building a Product Roadmap: Your First One Shouldn’t Be Perfect! appeared first on ProdPad.

5 steps to internal transparency

There are five steps – or levels – of internal transparency you can provide when you’re at a product company. From high-level strategy all the way down to customer feedback, you’re shifting the burden off yourself to keep your your colleagues – and empowering them to help themselves to the information they need to make good decisions.

You can introduce transparency at work starting today with documents you already have in ProdPad. Here’s how.

1. Open up your product vision

You probably already know the value of sharing your product vision – but do you do it enough? When it comes to product vision, it’s better to over-communicate than suffer through the consequences of not communicating it enough.

Our co-founder Janna Bastow once worked at a company where no one ever bothered to document a product vision. Then one day when the company sent a team out to recruit at a job fair, she and her coworkers could hardly keep their story together as they talked to potential hires.

One job-seeker even ended up asking her: “Are you sure you’re all working on the same product? I talked to a few of you about what your product is about and everyone gave me a different answer!” How embarrassing! 

Though the product vision is the highest level of transparency you can provide, it plays a really important part in how your coworkers understand their roles and the purpose of their work.

Marty Cagan of Silicon Valley Product Group points out:

When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day.  Strong technology people are drawn to an inspiring vision; they want to work on something meaningful.

If you already have a product vision, don’t be too shy to display it prominently in your office, to refresh everyone’s minds before planning meetings and to generally bring it up all the time. If they complain about it, tell them the people at ProdPad made you do it.

2. Open up your product roadmap

There’s no point treating your product roadmap like it’s a state secret, although we know some companies that do. (Why!?)

Your product roadmap is the single best way to communicate your strategy in a way that everyone understands – as long as you do it the right way.

The right way to share your roadmap is by defining a set of problems you plan to solve. No features, no timelines. That gives your colleagues the context they need to understand the direction your product is moving in, while still giving you the space to figure out what exactly you’ll do to solve it.

One way to make your roadmap really useful is to share different levels of detail with different audiences at your company.

For example, your CEO and exec team would probably be happy to review a high-level roadmap with you. What they want to see is the bottom line.

On the other hand, you’re better off sharing a highly detailed version with customer support, who need access to documentation, functional specs to handle customers and helpdesk tickets.

If you’re on ProdPad, we make this easy for you. You can create multiple versions of your roadmap and share the link (or embed) with each audience. Use this chart to help you figure out what you need to share with whom.

3. Open up your product backlog

You can be on your way to a solid product culture today just by forking over access to the product backlog to your colleagues.

Just like a Facebook post gathering likes and comments, people like to see their ideas get attention and feedback. It makes them feel heard and makes them likely to contribute and discuss ideas with you – and each other.

Barbara at Clicktime explains the profound difference it makes when you actually receive feedback on an idea you’ve submitted:

“It’s nice to have someone from the product team explain to you really clearly: ‘We hear your request and this is actively on our roadmap’ vs. ‘I don’t know if we’re ever going to do that.’”

In ProdPad, your colleagues monitor ideas and jump into the discussion early on. They can review ideas that didn’t make it to the next stage and find out why. They can also stay involved with an idea as it progresses and help shape the product spec.

4. Open up your product management workflow

Now we’re getting into truly transparent territory.

There’s no better way to communicate how the product team operates than by simply opening up your product management workflow and letting others peer in.

Workflows expand your power to share the stages through which you make everyday product decisions you make product decisions. They also empower your colleagues in marketing, support and sales to see what’s coming down the pipeline so they can prepare for the next release.

Launching a product or feature successfully requires a great deal of coordination across teams. With this view, your teams can quickly see where they need to focus, access details quickly, grab the docs they need and go. 

5. Open up your customer feedback

Think you’ve bared it all? Not quite yet!

The most valuable layer of information you can share across your business is customer feedback. But this critical layer of information – the primary source itself – is also often the least visible across company communications.

When you’re at a product company, making customer feedback easily accessible to everyone is the only way to keep a user-centric company…user-centric.

Remember, feedback isn’t just limited to customers sending you complaints on a website widget. It’s also the problems they tell you about on sales calls, on live chats, on social media and even at conferences. Every opportunity to improve your product, your marketing and your overall customer experience is hidden in what your customers are telling.

In fact, the most resourceful marketers have been known to “steal” their messaging ideas by digging into customer feedback. There are a lot of golden nuggets in there, so it’s in your best interests to make it easier for us all to see it.

We keep up with customer feedback at ProdPad is with our Slack integration. We pull in customer from services like Zendesk, Intercom and our customer feedback portal into the #feedback channel.

That gives us the initiative to monitor what customers are communicating to us and jump in to make improvements without waiting too long.

What next?

Believe it or not, you don’t have to be the boss to foster a product culture or a culture of internal transparency at your company.

You have the tools. You have the information. Now all you have to do is get it out there in front of your teams – then to get out of the way to let them do their best work!

The post Five Effortless Ways To Introduce Internal Transparency Into Your Organization appeared first on ProdPad.

Make design decisions based on data

Needing to get back to 1985, Marty seeks out Doc’s help. Unaware he had only just hit his head and came up with the concept of the flux capacitor, which would in turn set off a domino effect bringing Marty to his door in 1955, Marty now has to rely on his knowledge of the future to figure out a plan with Doc Brown. And fast.

Good thing Marty hands Doc a flyer from the future recounting the lightning strike. It’s this critical piece of information that Doc uses to design a plan to get Marty back to 1985.

“Data-driven design looks to ship fast, optimise at every step and let the data drive many of the design decisions. Often (but not always) it is possible to get large percentage improvements with small tweaks as pages have similar and standardised layouts, or a startup only has a few features to optimise for and one specific type of customer to speak to.” 

Alastair Simpson, Design Manager @Atlassian

Product managers should make informed decisions. When you’re looking at features to improve or retire, using collected data will allow you to ship fast and optimize your product quickly.

But how do you know which data to track?

Reddit Co-VPs of Product, Alex Lee and Kavin Stewart, recommend focusing on different thematic organization areas of the product, such as:

• Core product: How can we make typical use of the product better always?
• Signup experience: How can we bring more people into our product:
• Internal tools: How can we optimize the way we are working with infrastructure?
• Content: What content do we present to users and how?
• Community: How are we setting communities up for success?
• Channels: Where and how are we engaging with users outside the core product?
• Monetization: How do we sustain what we’re doing?

As First Round Review observes,

This cuts a ton of context switching out of your process. You reduce the number of people who work hard to solve problem A only to move over to an entirely unrelated problem B. You group people so they are always attacking grouped, interrelated problems that they know well.”

By narrowing your product work into focus areas so you can set up specific, tangible goals for each one.

There are several tracking tools that can track each thematic org area listed above, and by making this a priority and analyzing the data that comes through, product managers can then make accurate development changes and scale growth in a way that makes sense.

Plan with the technology you have, not hope to have

In all his genius, Doc Brown did not foresee (or chose not to consider) that 1.21 gigawatts of power was irresponsible and dangerous.

While his ‘for science!’ moment may have allowed Marty to travel to the past, they now relied on 1.21 gigawatts of power to get him back to the future.

Plutonium was certainly not going to be easily available in 1955, nor in 1985. But having the data at hand, they knew when and where lightning would strike to power up the flux capacitor with the needed boost. Even then, there were unforeseen snags that may have prevented the whole thing from happening.

So what can we learn from this?

Don’t get ahead of yourself.

Scale within your means and build with what’s available to you now. We all want to deliver great quality products, but putting ourselves in technical debt and not being able to support our clients can be more damaging in the long run.

Have your roadmap out for inevitable detours

We may not need roads, but we do still need roadmaps.

Whether Biff ruins your plans or you slip from the top of the clocktower while trying to plug cables together, always remember that life happens. There are things that are just completely out of your control.

At times like these, roll up your sleeves and throw your time frames out. You’re going to be here awhile, and nothing’s going to work out like you thought it would.

The mission hasn’t changed. The vision hasn’t changed either. But the way you get there will.

We product managers have product roadmaps for that.

Your product roadmap serves as a communication tool, outlining your vision and direction.

It also acknowledges the real world – a world that will give us engineering challenges, communication breakdowns, and unexpectedly demanding customers – and gives us the flexibility to accommodate them all.

Use your data to make your own path

In BTTF2 Marty gets a sneak peek at his future, a future he’s already dreading. Due to an accident during a drag race, Marty hurts himself and is unable to play guitar, which makes him angry…and we know that anger leads to hate, and hate leads to suffering.

All this just because some bullies taunted him into doing something stupid.

The big lesson here: Don’t just do things because other people are.

You have your data, you have your feedback. Now use it to solve the problem, even if it doesn’t look like what everyone else is doing.

As Paul Graham once said, “Most startups fail because they’re trying to solve a problem that doesn’t exist.”

And that’s what we do: we solve problems our way, for our customers. If what we’re doing has been done before, then what are we in business for?

Keep your eyes open for the ‘pivot’ moment

As he’s being chased by Biff and his goonies, Marty borrows a kid’s box-cart scooter and turns it into a skateboard to get away. His quick thinking allows him to get away, while Biff and gang end up in a pile of fertilizer.

This is what we call the pivot moment.

It’s that moment when you realize the solution in our head doesn’t matter. It’s about solves the problem, whatever that looks like.

Doc Brown used a train to push the Delorean to 88MPH.

So why can’t we also be flexible and creative with our solutions right here in the present?

After a hilarious conversation in MTP’s Slack Channel about Back to the Future and how it relates to product management, I felt compelled to dig deeper into the connection between one of the greatest trilogies ever created and our rockin’ jobs.

Thank you to everyone who participated! This one’s for all of you.

The post Why Every Product Manager Needs A Flux Capacitor appeared first on ProdPad.

People want to talk about that roadmap

You may know that at ProdPad, we communicate our plans on a theme-based roadmap. You won’t find any features or deadlines on our roadmap, because themes give us way more flexibility to change our plans and priorities. (You can create one too using our product roadmap tool.) 

We stay relatively vague, to give ourselves the freedom to shape and pivot until we move forward on a solution. Yet this has never been a deal breaker for our customers. 

Quite the opposite, actually.

Our roadmap has kicked off conversations that have gone on to directly influence our product decisions. It’s an opportunity for our customers to tell us what they’d like to see. More importantly, it’s an opportunity for them to see what we’re up to without getting caught by surprise.

For example, when we first put SSO on the roadmap (based on initial feedback from customers), we didn’t know what we were going to build. But we had a public roadmap and asked customers what they thought of the idea. 

We learned from them that the Google Apps SSO integration would have a much bigger immediate impact than some of the trickier solutions we were considering.  Eventually, we moved forward with what our customers suggested and saved ourselves the pain of building an overly sophisticated feature our customers wouldn’t value as much.

Or take this for example: In the Future column, we have a Mobile/iPad theme.

We know won’t get to building an app for awhile, but just having it sitting there on our roadmap led to a feature that our users themselves brought to our attention.

When we started asking what was important to include in a mobile version, we learned that our users wanted to be able to organize their ideas and feedback ProdPad while they were commuting or on a flight.

That led to the launch of our offline mode, giving them basic access to a small number of tasks while they’re on-the-go. We don’t have a mobile app (yet!), but that conversation helped us respond by building the functionality that really mattered to them.

Customers love the transparency

We’ve found that as long as we’re open and honest about our priorities, customers are actually very forgiving. We hold onto the feedback we get and reach back into it to guide the way we approach their problems – and our customers know that.

These conversations have helped us understand what resonates with people, and that helps us position our launches down the line. 

We don’t bow to the pressure to make false promises. We don’t have a problem telling customers that something they’ve requested isn’t going to get built. We stick to our priorities (although we do shuffle them around as needed).

Since we’re all looking at the same roadmap, we’re all on the same page.

Have you thought about going public with yours?

Update: We’ve developed an e-course to help you set up and introduce a theme-based roadmap at your organization. Sign up here.

The post Radical Transparency: Our Product Roadmap Is Public And People Love It appeared first on ProdPad.

“What tools can I use to keep track of feature requests?”

That question got me thinking about the implications of product managers tracking feature requests as if they were a growing to-do list. Here’s how I responded on Quora:

“Don’t consider them feature requests, consider them customer feedback. Customer feedback can be good or bad – but regardless, it is still useful to understand your target, along with their frustrations, limitations, wants, needs, and ways to improve your product.

You can then use this feedback to better prioritize your backlog. This backlog will include ideas from your team, customers, management, and stakeholders. Of course, you can do much more than just sort by what we call “customer desire” – you can add impact and effort, sort by roadmap, product, tags, and much more – allowing you to prioritize your roadmap and keep focus on your product vision.”

Feature requests often come from a genuinely helpful place, but what are they really? It’s just someone telling you they’d like for you to change something that isn’t working for them. You don’t have to legitimize each and every one. The request is valuable as feedback, but you don’t have to bump it up to the front of the line because it came in as a feature request. 

Customer Feedback

What happens if you simply consider a feature request as customer feedback? I can think of at least a couple of things:

• Empower yourself to choose what gets built – Hey product managers, this is where I want you to get up, raise your arms, and scream ‘yaaaaas!!!’ because this power is exactly what you need to do a better job as a product manager.
• Investigate why they suggested it in the first place – You can take the time to dig into the underlying reasons that a customer sent in a request, and look into whether other users have sent in similar feedback. You can then prioritize feedback as it comes in without over-promising, under-delivering or upsetting anyone.
• Keep the feedback flowing – I never said the customer wouldn’t be able to still influence what you do. When customers realize that you consider all their feedback to help you decide what’s next for your product, you’ll get more of it.  

As a wise woman once told me, “You are not your market.”

Use this opportunity to understand your audience, learn from them, and make actionable changes that improve both your product and keep your clients happy. (And by “wise woman” I am really referring to our CEO Janna Bastow.)  

So what should you do with customer feedback?

So what do you do with your feedback once it comes in?

1. Tag each item that comes in so later you can filter
2. Sort through them to see how many popular an idea is
3. Determine how much effort it would require and how it might affect the product’s popularity.

Once you’ve weighed these factors against one another, you can start prioritizing all this feedback. If there’s a particular piece of feedback that’s just so good you decide you absolutely must consider it in your backlog, upgrade it to an idea. 

From here, you can start developing it into an actionable task. 

Contact the customer(s) that sent that feedback through and find out what led them to leave that feedback, and what their circumstances were, so you can build the business case for the idea with real customer data. (Customers love it when you contact them about their feedback, by the way.) 

Then start spec’ing it out. Convert it into something you could possibly work on and start discussing it with your team. What do they think? What do they want to see reflected in the business case? How much effort do they think it will require? 

Once you’ve completed the spec, add it to your roadmap. 

Final thoughts: Don’t put feature requests on a pedestal

By starting from your pool of customer feedback, you actually end up giving more power and consideration to your customers.

You listen, understand, investigate, and deliver on feedback they gave you – and then you actually follow up on it. There’s nothing as satisfying for a user than when they feel like they’ve had a positive impact on what you do. 

Your customers will feel like you are actually listening to them and that their feedback really is a part of how you improve your product. 

The post Try Not To Be A Slave To Feature Requests appeared first on ProdPad.