Published on | Prototyping: From UX to Front End — Medium Dave Collins Photo by Cristina Gottardi

Product management can be a tough gig. The role covers a broad range of disciplines and responsibilities, probably more than any other job in the tech scene . So it’s a challenge knowing which path to focus on, which tends to vary from one company to another. Because of this general role ambivalence, it’s not unusual for product managers to assume responsibilities peripheral to the role, which can lead you down the path of limited effectiveness.

With this in mind, here’s some tips to make the best use of your precious time and to help ensure you become the impactful product manager that you want to be.

1. Lead with a vision, objectives and empathy for your customers

Know the company vision. You don’t have to come up with one, it should already exist. Any idea that you and your team come up with needs to support the vision. There’s plenty of vision examples out there, like the below one from Ikea.

Ikea vision “To create a better everyday life for many people. Our business idea supports this vision by offering a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”

A vision statement is nice, but supporting objectives (the what) and key results (the how) are needed to provide a better sense of alignment and progression towards living it. Again, your company objectives and key results (OKR’s) should already exist (in some shape, way or form) and usually align to key customer journeys. See Uber’s objectives example below.

The objectives of Uber.

Each of the above objectives needs to have supporting key results. For example the objective of ‘MORE DRIVERS’ needs to have the key results of

Increase driver base in each region by 30%
Increase driver average session to 30hours / weekly in all active regions

With the company vision and OKR’s down pat, you have a basis to lead with. You also need to have this direction in place to start discovering ideas that will shift you there.

2. Product discovery is your core competence

Marty Cagan put’s it nicely “the aim is to prove that your ideas are valuable, usable, feasible and ethical with customers”.

Getting this validation requires you to get some form of a prototype in front of users as quickly and cheaply as possible. You’re essentially listening to customers and looking for early qualitative insights to filter out the good ideas from the bad ones.

To prepare a prototype fast you need tight collaboration with your designers. Co-locate them with you and your delivery team to ensure this happens. Regular feasibility checks with engineering of course are essential, they can let you know what’s technically possible because they’re neck deep in the domain everyday. Involve them early. Involve them often.

The more user testing you do the more you’ll discover, so be pragmatic about it. The best discovery processes are optimised for multiple testing sessions a week, imagine that!

<a href="https://medium.com/media/9162bacd727dc13a5456b686756424f6/href">https://medium.com/media/9162bacd727dc13a5456b686756424f6/href</a>

Quantitative a/b testing should be another important tool in your product discovery tool kit. It usually comes after you’ve started to build the best ideas (confirmed by your user testing). It helps you answer a different set of questions, like what quantitative impact is this initiative going to make on converting users through the product? Will this initiative make a positive impact on our OKR’s? People tend to be in one camp or the other when it comes to user testing vs. a/b testing. It’s your job to realise they are both important for different reasons.

3. Over-communicate, but stick to the point

Be on the front foot with communicating the results of your product discovery work. To peak engagement, lead with insights and results and articulate how they address user needs and impact OKR’s. Try to respond with encouragement when other product mangers are doing the same, they’ll really appreciate it.

Be transparent with your delivery team. Keep them across your plans with other areas of the business — most importantly let them know the why for these dealings. Keep them across the performance of the business, your product, the performance of a/b tests, product discovery insights and customer feedback trends. This provides context around what they could be working on next.

Your work can help make or break other departments in the business so you need keep be in sync with them constantly. It could be GTM managers, marketing, legal, customer care, sales, product managers from other departments, your manager, other managers — anyone. The point is, lines of communication should be constantly flowing. Reoccurring catch ups are an obvious way to do this, but keep them structured. Think about your agenda items and send them through in advance (if you have nothing, it’s okay to postpone), write and assign actions and ask for updates in the next catchup. This sounds obvious, but it doesn’t happen that often.

4. You’re not a project manager…

You’re not hired to keep work flowing smoothly through a delivery team, or to ship features on time. So, If you find yourself being solely responsible for things like release planning, running retros, showcases, stand-ups or grooming sessions; your time and attention in the areas that matter the most will take a hit. Don’t be lulled by the sense of satisfaction felt by keeping a team running well. You’ll probably end up being one of those well-run teams, working towards a product that no-one wants, because your discovery investment was too light on.

5. You’re not a tester either…

Be careful that the task of product verification is not misinterpreted as product testing. For me product verification means checking a (dev and test) complete story to ensure the acceptance criteria (that you should have defined) are met. If you find yourself spending excessive amounts of time, not only verifying, but also doing things like explorative testing, regression testing, testing on multiple phones, tablets, orientations or internet strengths — don’t! It’s not the best use of your time and the delivery team are there to ensure quality standards are met, via automated and manual quality assurance measures.

6. You’re the master of scope

I try to keep a simple rule; If a task is scope related i.e. backlog prioritisation, writing acceptance criteria, grooming a story with engineers in preparation for development or story verification. This is your area to keep on top off to help ensure the team runs smoothly. Own these tasks with passion!

7. Know what tech innovation mostly means

A lot of us tend to think of tech innovation as the most currently marketed capabilities like Machine Learning, Augmented/Virtual Reality and autonomous cars. Innovation however, more commonly comes from the fundamental ideas engineers have that allow for the improvement and scaling a features for full production use.

These are ideas around making code more intuitive and sustainable for future engineers to work with, ideas that allow capability to be reused, that allow products to load faster, that improve uptime, that make products more robust, secure and reliable. You need to understand the immense value of this work and make way for it. Denying engineers the opportunity to innovate in this regard, will come back to bite you big time further down the track. This is particularly important when scaling a successful a/b test variant. I’m all for faking it until you make it, just as long as you don’t fake it anymore, once you’ve mad it.

8. What kind of analyst do you work with?

You may come across different kinds of business analysts during your career, such as analysts responsible for defining low level detail and analysts responsible for data.

When it comes to matters of lower level scope definition, it should be lead be product, in consultation with design and engineering— if your going to manage a product you need to know how it works intimately, right? If you have an analyst in the team trying to do the same thing, there’ll be too much overlap on this task, creating inefficiencies due to role confusion and competition.

Working with an analyst responsible for data on the other had, can be hugely beneficial. They should be there to enable you and the team with the right tools (for reporting, a/b testing and what ever else you need to measure), the right processes (to design, implement and test tracking code and experiments) and to be able to interpret data correctly. This leads me to the next tip…

9. Own your data

I’ve recently come to the conclusion that product managers should also be responsible for tracking details, right down to the definition of goals, events and dimensions used for tracking and a/b testing tools. These things are really important extensions of the core products definition, it’s scope for you to own.

There’s on overhead to adopting this skill initially but it pays of, as you’ll soon have a more thorough understanding of, and confidence in the data that your product and customers produce. This will show in the way you communicate findings and impacts to stakeholders and the business.

Closing thoughts

The main aim for product managers it to know your company direction and customers intimately. Use this to direct your product discovery efforts, as this is absolutely your main competence and reasonability.

Marty Cagan linking OKR’s, product discovery and delivery to prove Product/Marker Fit.

Ultimately you want to create an environment that allows you to pull the great ideas into production once the validation is there. This works best when you commit to solving customer problems and positive impacts to OKR’s, and not to features on a road map. Understanding and adopting the processes of Deign Thinking, Lean and Agile are critical in setting up this way of operating. This sets the best companies apart from most companies. Jonny Schneider wrote a fantastic book to help in these areas, aptly named “How Design Thinking, Lean and Agile Work Together”.

In order to achieve the above, be mindful about how you contribute to peripheral areas. You can still lead delivery teams without being a project manager. After all delivery teams are only as good as the products the deliver and it’s your job to ensure they deliver the right ones.

9 Tips to help find the right path as a Product Manager was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

9 Tips to help find the right path as a Product Manager

Cool stuff, every week

More Articles