Showing posts with label product owners. Show all posts
Showing posts with label product owners. Show all posts

Friday, March 1, 2019

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.

Thursday, February 28, 2019

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.
Image of a product roadmap in Jira
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. 
A product roadmap with detailed development tasks
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.
A lightweight product roadmap for executives
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.