19 Lessons I Learned During My First Year as a Product Manager

This was a guest post contributed by Manas Saloi, who recently reached his 1-year mark as a Product Manager at CouponDunia

https://www.productmanagerhq.com/2016/03/19-lessons-i-learned-during-my-first-year-as-a-product-manager/

2015 was a big year for me professionally. I transitioned from coding to product management. While I’m constantly learning and have a long way to go, I want to share a list of 19 things that I’ve learned last year:

1) Get your priorities straight. The first 30 days at your new job are critical in setting expectations with the management as well as getting familiar with everyone in your team. Start early. Dig in. Create a reputation as someone who gets shit done.

2) One of the hardest things to accept when you first transition into a product management role is that you will no longer be writing code, creating beautiful UIs, running marketing campaigns or whatever you were doing on a regular basis before making the switch. Your only goal now is to make sure you help your team ship the right product to your users. You are now an owner of the product without any of the stake- holders directly reporting to you. This will mean being a champion for your developers when talking with management (setting timelines), fighting for your marketing team when they need a feature to be shipped which might not be considered a priority by others. Essentially, being the voice of all stakeholders involved with your product/company. Your job now is to remove roadblocks and help people do their job well.

3) Don’t code. Don’t design. Don’t run marketing campaigns. You are a facilitator whose job is to make life easy for your team members and not do their job. One of the first bad mistakes I made was changing the color scheme of our app without even discussing it with our design lead. This is probably due to all the articles I had read on product management which led me believe that the role of a PM is similar to a CEO. It is not. Product Manager You Are…a janitor, essentially.

4) Create transparency. I am a big fan of Buffer in this regard. One of the first things we built after we shipped our product was an internal dashboard to monitor all our internal KPIs (including revenue data). And it is accessible to everyone associated with the product (CashBoss). During our monthly meeting, our updates were tangible (numbers, stats) so that everyone in the company could understand how well/bad our business unit was doing. This creates accountability.

5) Avoid inertia. The law of inertia states that it is the tendency of an object to resist a change in motion. That is, an object at rest will stay at rest, unless it is acted on by an external force. Often we keep avoiding tasks which might not appear important at present but skipping them altogether can have major consequences. I remember I missed out on getting our credits recharged with our SMS provider. We used their service to send an OTP (one time password) to our users during the registration process. We assumed we had enough left when suddenly one day we woke up to a bunch of one star ratings from our users who were unable to sign up. As I already mentioned – the buck stops with you as a PM. If a major screw up like this happens own up to your mistake and set up processes to avoid a repeat of the same mistake in the future. Learn to take the blame when things go wrong.

6) Account for testing in your timelines. For a new product let your alpha users test it for a minimum of one week and then release it to a slightly larger user base of beta users. After you are done don’t make any more last minute additions. We had a major bug when we released our first build because of trying to ship things that weren’t a part of the original roadmap. Check the performance in all devices and Android versions before going live. Even small things like your placeholder image loading correctly and the database/server instance you are using.

We had kept the smallest instance even months after going live.

Even if you are getting all the correct responses on your API calls, you should still check it in action on your app. Once one of our devs only checked the change in API response and pushed the app to production. But due to some error the same response was not coming on the device. As a PM you are the unofficial QA. You have to test the final builds before you release them to production.  Create have a check list that you go through every single time you’re pushing your app to production to make sure everything is working as expected.



7) Lead from the front. When we used to work during weekends while building the app our CEO used to join us too. In a similar way as a PM you have the set the example when it comes to work ethic. If you are a workaholic who shows up on time everyday your team will follow. If as a manager you start slacking off, your team will follow a similar approach to work.

8) Keep asking what you are not doing every week. Set one on ones with your team members and get feedback. Understand the pain points. Most teams have regular stand ups for the sake of it. The goal of stand ups is not to get status updates but to figure out the road blocks and remove them.

9) It is your responsibility to show up with a positive attitude every day. I had a tough time doing this always. But I hope with time I will be more efficient at this. As a PM you are the cheerleader of your team.

10) Getting new users is much costlier than retaining older ones. Have a clear user acquisition policy from day one. Set up user on boarding to prevent users from prematurely leaving your app/site. Set up cohorts. Have something for users to reach their ‘aha’ moment ASAP. Unless you have that every new user gained might be a waste of marketing dollars. Have analytics in place. Set goals. Measure the lifetime value of your users. One of the main reasons startups fail is because they can’t convert their users to power users.

11) Small things done right will lead to massive improvement of your app performance over time. You don’t have to always focus on the next big app update. Fix the small bugs first. Focus more on user experience.

12) Sometimes you have prioritise thinking 6 months ahead. We should have started capturing geo location of users from day one. This would have helped us run location based offers later on. This made me realize why it is so much important for a Product Manager to not just have a micro view but also the macro.

13) Have a priority list and ruthlessly prioritize what to build. Time management is major key.

14) Don’t get emotional over user reviews. Consider them as another data point. As a PM your product is like your baby. It is a hard time accepting criticism. But that does not mean you  write ‘K’ as a response to a Play Store review. I was once close to doing that once before someone knocked sense into my head (Thanks @Aamna Khan).

One of my current goals is to prepare a list of 1 star reviews every week and address them (possibly in a blog post).

15) Spend time training new employees especially interns. At least a few hours each week should be spent on knowledge transfer. Read how Planet Labs turned Its Interns into Company Leaders with This Program. One thing I always encouraged my developers to do was read more. It is tremendously important to keep yourself updated with industry standards.

16) Have courage to make big decisions and stand by them. If they go wrong take the blame. No one will probably give you any credit when they succeed. But that is alright. This is what separates good leaders from bad – The ability to make decisions and stick by them. Read: Speed as a Habit

17) On board new employees well. The first day is extremely crucial. Help them settle in. Fix a mentor. Similarly spend time reading exit interviews. It will help you learn how to increase employee retention.

18) Have customer service in place since day one. This means you my friend. Till you have a full-fledged customer support team, you as a PM have to reply to your users. Fix their problems. Just like you have to be the first QA.

19) “I always felt product management was one of the most important functions that when done well, helps make companies and products much better, and when done badly, can really hurt a company and team.” – Josh Elman talking about the PM role.

I truly believe that. As a PM you are the super user of your app. You are the one who is ultimately responsible for shipping the right product to the right users. You are the voice of your users. There is no greater feeling than seeing people leave positive feedback on your latest build.

It has been a wonderful first year learning how to build products and I am looking forward to write more in 2016.

12 Things Product Managers Should Do in Their First 30 Days at a New Company

Ken Norton

Jul 29, 2014

Congratulations, a product has found its product manager. Perhaps you’re joining a small startup, or maybe you have a new project in a big company. How you approach your first 30 days will make a tremendous difference, setting you up for success or struggle.

Here are some tips for how to approach that first month. Emphasize these three areas: People, Product, and Personal:

People
1. Set clear expectations with the CEO or your manager
You’ve been hired to fill a hole, and there will be organizational pressure for you to contribute immediately. Review your objectives with the CEO to make sure they have the right expectations for what you’ll be doing. Your primary goal for the first month is to effectively join a team.

2. Schedule a one-on-one with everyone on the team
Depending on the size of the company, this may take a few hours or the entire first month. Find time to meet with everyone individually.

I prefer walking one-on-ones — there’s something focusing and invigorating about walking together and looking ahead as opposed to staring at each other across from a conference room table.

3. Ask everyone this question
“What can I do to make your life easier?”

You’re showing that you’ve here to help, not to command. How they answer is almost as important as what they say. You’ll get a true indication for how they perceive the PM role, and what they need from you.

4. Take a load off their back
Hopefully you’ll walk away from the meeting with something you can take from them that’s cutting into their productivity. Maybe an engineer would love for you to take over bug triage. Or weekly Costco runs.

Product
5. Schedule time with your lead engineer to walk through the product’s technical architecture, in deep detail
Don’t shy away from asking questions or drilling down on things that didn’t quite make sense.

Too often PMs try to impress their engineers with their technical acumen, but in my experience engineers are much more impressed with PMs who are willing to ask questions and say “I don’t understand that.”

6. Resist the urge to jump in and start changing things
You’re going to want to start making changes to the product and the development process. I recommend holding back a bit in the beginning.

Your ideas and thoughts will be better formed after you’ve had a chance to settle in, gain credibility, and absorb all of the nuances. You’ll also be demonstrating that you’re a listener.

7. Get in front of your users
Spend a solid chunk of your early days with your users. Go on sales calls and customer visits. Take some support tickets. Get on the forums, engage with users on Twitter.

8. Fix something
I’m a firm believer in PMs being technical, and an excellent starter project is to fix a bug or launch a minuscule feature on your own.

Set up a dev environment and ask for something bite-sized that you can do. Ask for help and be considerate of your time and the team’s — you’re a PM after all, not a full-time engineer.

Personal
9. Read everything, and write it if it isn’t already written
Read anything you can get your hands on — old OKRs, specs, design documents, wiki pages. As you find documentation that is missing or out of date, add it. Take time to write up what you’ve learned and how things can be improved for the next hire.

10. Set some personal goals
Changing jobs can make you feel heroic about some things and woefully clueless about others. This is a chance to set some personal development goals. I like to keep it simple:

What is one thing you do really well that you want to continue to do? How are you going to stay in the habit of doing that?
What is one thing you need to improve at? What steps are you going to take to get better, and how are you going to measure your progress?

11. Configure your life support systems
Get all your tools and devices in order. Install the software you need. Create email filters. Set up Google News Alerts for your product and your competitors’ products.

12. Have fun!

https://library.gv.com/12-things-product-managers-should-do-in-their-first-30-days-at-a-new-company-326f1a4ae53b

User stories are development tasks often expressed as “persona + need + purpose.”

It's tempting to think that user stories are, simply put, software system requirements. But they're not. 

A key component of agile software development is putting people first, and user-stories put actual end users at the center of the conversation. Stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building what they're building and what value it creates. 

User stories are one of the core components of an agile program. They help provide a user-focused framework for daily work — which drives collaboration, creativity, and a better product overall.

What Are Agile User Stories?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

The purpose of a user story is articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day to day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

Learn more about epics and initiatives

Why Create User Stories?

For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.

User stories serve a number of key benefits:

• Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users.
   
• Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
   
• Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
   
• Stories create momentum. With each passing story the development team enjoys a small challenges and a small win, driving momentum.  

See how user stories work in Jira Software

Working with User Stories

Once a story has been written, it’s time to integrate it into your workflow. Generally a story is written by the product owner, product manager, or program manager and submitted for review.

During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint. Teams now discuss the requirements and functionality that each user story requires. This is an opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon, these requirements are added to the story.

Another common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon.  

How to Write User Stories

Consider the following when writing user stories:

• Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
   
• Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
   
• User personas — For Whom? If there are multiple end users, consider making multiple stories.
   
• Ordered Steps — Write a story for each step in a larger process.
   
• Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
   
• Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
   

Once the user stories are clearly defined, make sure they are visible for the entire team.

User Story Template and Examples

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down: 

• "As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.
• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

For example, user stories might look like:

• As Max, I want to invite my friends, so we can enjoy this service together.
• As Sascha, I want to organize my work, so I can feel more in control. 
• As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and failures. 

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it.

Getting Started with Agile User Stories

User stories describe the why and the what behind the day-to-day work of development team members, often expressed as persona + need + purpose. Understanding their role as the source of truth for what your team is delivering, but also why, is key to a smooth process.

Start by evaluating the next, or most pressing, large project (e.g. an epic). Break it down into smaller user stories, and work with the development team for refinement. Once your stories are out in the wild where the whole team can see them, you’re ready to get to work.

https://www.atlassian.com/agile/project-management/user-stories

Win everyone over with your roadmap

The presentation of a roadmap can be nail biting for both developers and product managers; one party has worked hard to come up with a vision while the other party waits to see the unknown that is going to affect their work.

I felt this tension when I worked as a developer and I often found myself unsatisfied with the roadmaps product management put together. I didn't fully buy into the decisions, and I'd often walk out of a planning meeting with the sentiment of "Well, this doesn't make sense to me, but if they think so...", or even worse, a "We'll have to figure out things ourselves and make it look like what we do fits this roadmap.

You might argue the problem was likely me suffering from NIH (Not Invented Here syndrome) and you might be right. As a developer, I had a very strong opinion on what was the right thing to do. But now as a product manager, I see what caused this disconnect, and what general learnings product mangers can draw from this disconnect to hit a homerun with your next roadmap presentation. After all, if the technical team agrees with and understands the big picture, day-to-day design and implementation decisions will be made with the right context, and you’ll get the product you envisioned.

1. Choose substance over buzzwords

Whilst buzzwords like “big data analytics”, "machine learning," or “an Internet of Things initiative (IoT)” might resonate with business stakeholders as high-level anchor points, they aren't helpful and actionable items for technical teams. Engineering needs to know exactly what it is they're building, how it relates to current products, how it should be delivered, and who will use it in the end, and for what purpose.

Setting high-level themes is great for structuring the roadmap and context, but make sure you don’t stop there and have good answers for what is behind each high-level item. For example, if you've called a theme "intelligent services," make sure to break this down into key initiatives and epics that are needed in order to deliver this theme.

2. Set the right context

Technical teams need context for why you are building something on a roadmap. No technical team is going to say, "Just tell me what you want and I’ll build it." On the contrary, engineers need to see evidence for why you see demand for a feature. Let data speak, but also tell a powerful story from the perspective of your users. Use personas, and talk about some alternatives that you've excluded, and why. To help the entire team understand the roadmap the "why" matters as much as the "what."

3. Consider commitments carefully

If a feature doesn't seem well thought through or realistic, yet it is still on the roadmap, this should scream red flag. You don't want the technical team getting the impression that they have to build stuff just because you promised it to someone. This could be a commitment to a customer or because because "management wants it." So be wise about making commitments. Even if you have a forcing function behind yourself that requires a particular change, make sure you understand and pass on the rationale to the team, and stand behind it yourself.

4. Make realistic plans

A vision is good, but it’s even better if everyone feels confident that it can be achieved. The plan doesn't need to be precise, but if the first thing your development manager sees when looking at a roadmap is a huge bottleneck – for example, if the roadmap looks design heavy and frontend centered, but the team only has one designer and has struggled with frontend topics in the last few months – then you'll have he or she struggling with the roadmap throughout the rest of your presentation.

Make sure you do a reality check upfront with the team and play with what-if scenarios. You need to have answers, a clear plan of action, and concise consideration about the "how it can be done" before asking for everyone's commitment. 

5. Think big, start small

You need to be aware of where a product and team skills are today versus where you want them to be. It's great to advance into new fields, which might require new skills in the team or moving away from existing technology, but don’t just write down dreams of where you’d like to be in a year. Instead, think about how to get there realistically. Acquiring talent takes time, adopting new technologies takes time, and abandoning existing products requires clear commitments and a transition plan.

6. Build a business case

Business case? Yes. Technical teams care about businesses cases. Maybe not to the same extent as senior management, but an entire development team cares about why something is relevant to the business, if it produces real results, and how this will be measured. Tap into the business-street-smarts of your technical team. Everyone has a vested interest in the business succeeding as a whole, and it can be great source of feedback or additional ideas.

Also, full clarity on the business impact and seeing it happen can be a great motivator; driving results is satisfying beyond just having built and shipped a feature.

7. Balance mundane with motivating

Engineers want to build unique, innovative products that they can take pride in. If it's just the same old story others have told before, it can be demotivating. Make sure you do research to confirm that your story is as innovative as you think. Aside from demotivated developers, the business impact of the lack of innovation is even worse.

With this said, even roadmaps will always be a balancing act between exciting new features, and technically not too interesting must-haves that just have to be done. Try to make sure that even the mundane is motivating on your roadmap. 

8. Think beyond MVP and v1

Creating a minimum viable product, and then a version 1 is one thing, but there’s also everything that happens post-launch: operations, maintenance, feature requests from users, continuous improvements, and new versions of other products and/or platforms that are integrated. A quick think on what the challenges and obstacles might be after a launch will bring these to light without much effort, and engineers will be thankful that you didn't ignore these realities. Rough estimates suggest that the initial effort of building a new feature is often only a third to one half of the total effort spent on it over its entire lifetime. In other words: the aftermath is more costly then the initial build, and some "quick small things" become very costly in the long run.

9. Roll with the punches

Estimates are a good thing. They give you guidance, and are created to the best of a product manager's knowledge at each given point in time. However, many assumptions made for estimates turn out very wrong once you go into implementation or refine a design. Make sure you prepare and present the roadmap so that it’s flexible to changes.

10. Be open and honest

A roadmap is there to provide guidance. It’s not a detailed plan for execution and everyone on a software team knows that. There's no need to sell it as something different than it is. So if you don’t have all the details on a topic yet, be open about it. Share what you have, what the intention is, what the open questions are and highest risks that still need to be addressed. Point out areas that require experimentation and more research to nail down the "what." Just remember to account for this experimentation time in planning.

The bottom line?

Your team deserves a roadmap that clearly paints the big picture, but doesn't neglect realities. Your team also deserves a roadmap that is motivating, exciting, and has enough details so the entire software team knows what to do in the next 1-2 sprints with a feeling of confidence that they'll achieve great results with material impact for the business.

Cheat sheet: top 10 tips for getting buy-in from your technical team

A product roadmap is a shared source of truth that outlines the vision, direction, and progress of a product over time.

A product roadmap is the key to communicating how short-term efforts match long-term business goals. Understanding the role of a roadmap—and how to create a great one—is key for keeping everyone on your team headed in the same direction.

What is a product roadmap?

A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short- and long-term goals for the product or project, and how they will be achieved.

While it's common for the roadmap to show what you’re building, it’s just as important to show why. Items on the roadmap should be clearly linked to your product strategy, and your roadmap should be responsive to changes in customer feedback and the competitive landscape.

Product owners use roadmaps to collaborate with their teams and build consensus on how a product will grow and shift over time. Agile teams turn to the roadmap to keep everyone on the same page and gain context for their everyday work and future direction.

Who are roadmaps for?

Roadmaps come in several different forms and serve a variety of audiences:

Internal roadmap for development team: These roadmaps can be created in several ways, depending on how your team likes to work. Some common versions include the detail about the prioritised customer value to be delivered, target release dates and milestones. Since many development teams use agile methodologies, these roadmaps are often organized by sprints and show specific pieces of work and problem areas plotted on a timeline. 

Internal roadmap for executives: These roadmaps emphasize how teams' work supports high-level company goals and metrics. They are often organized by month or by quarter to show progress over time towards these goals, and generally include less detail about detailed development stories and tasks.

Internal roadmap for sales: These roadmaps focus on new features and customer benefits in order to support sales conversations. An important note: avoid including hard dates in sales roadmaps to avoid tying internal teams to potentially unrealistic dates.

External roadmap: These roadmaps should excite customers about what’s coming next. Make sure they are visually appealing and easy to read. They should provide a high-level, generalized view of new features and prioritized problem areas to get customers interested in the future direction of the product.

Why should I create a product roadmap?

The biggest benefit of the product roadmap is the strategic vision it illustrates to all stakeholders. The roadmap matches broader product and company goals with development efforts, which align the teams around common goals to create great products.

• For organizational leadership, the roadmap provides updates on the status of work and “translates” developer tasks in Jira into non-technical terms and a format that’s easily understood.
• For product owners and managers, roadmaps unify teams working on high impact product enhancements and allow them to communicate priorities effectively with adjacent teams.
• For the developers themselves, roadmaps provide a better understanding of the “big picture,” which allows team members to focus on the most important tasks, avoid scope creep, and make fast, autonomous decisions.

How do I build a product roadmap?

To build a roadmap, product owners should consider market trajectories, customer value propositions, strategic goals, and effort constraints. Once these factors are understood, the product owner can work with their team to start prioritizing initiatives and epics on the roadmap.

The content of a roadmap will depend on its audience - a roadmap for the development team may cover only one product, while a roadmap for executives can cover multiple products. Depending on the size and structure of an organization, a single roadmap may span multiple teams working on the same product. An external roadmap will often cover multiple products aligned with one point of emphasis or customer need.

The most important takeaway: create a roadmap that your audience can easily understand. Providing too much or too little detail on the roadmap can make it easy to gloss over, or worse, to too intimidating to read. A roadmap with just the right amount of detail and some visual appeal can earn the buy-in you need from key stakeholders.

Presenting the product roadmap

The product roadmap needs buy-in from two key groups: leadership and the agile development team. Presenting the roadmap is a great opportunity to demonstrate to key stakeholders that you understand the company’s strategic objectives, the needs of your customer, and have a plan to meet them both.

We have a dedicated page on presenting product roadmaps here. 

As you move through the project, make sure to link your team’s work back to the roadmap to build context. A tried-and-true method: break initiatives down into epics in the product backlog, then further decompose them into requirements and user stories. Establishing this issue hierarchy makes it easier for product owners and the development team to make decisions and understand how their work fits into the bigger picture.

Using and updating the roadmap

As the competitive landscape shifts, customers' preferences adjust, or planned features are modified, it’s important to ensure the product roadmap continues to reflect the status of current work as well as long-term goals.

The roadmap should be updated as often as necessary - this could be every week or fortnightly - so that it can remain an accurate source of truth. As we’ve all experienced at one time or another, a roadmap is counter-productive if it isn’t up to date. You’ll know if your roadmap needs to be updated more frequently because your stakeholders will start calling you for updates instead of consulting your roadmap. These one-off requests reflect a distrust in your roadmap, and a huge potential time suck.

However, on the flip side, you don’t want to spend more time updating the roadmap than is necessary to achieve alignment between stakeholders and within your team. Remember, the roadmap is a planning tool to think through how to build great products. If you’re spending time updating your roadmap that you could (and should) be spending on execution, think about changing your roadmapping tool to something more simple.

Best practices for the best roadmaps

Building and maintaining product roadmaps is an ongoing process to embark upon with your team. There are a few simple ways to set yourself up for success:

• Only include as much detail as necessary for your audience
• Keep the roadmap evenly focused on short-term tactics and how these relate to long-term goals
• Review roadmaps on a regular basis and make adjustments when plans change
• Make sure everyone has access to the roadmap (and checks it on a regular basis)
• Stay connected with stakeholders at all levels to ensure alignment

Ready to make your very own roadmap? Jump into the new roadmap feature in Jira Software and start to prioritize and plan your epics with your team.