“Draw the art you want to see, start the business you want to run, play the music you want to hear, write the books you want to read, build the products you want to use, do the work you want to see done.” Austin Kleon

What does it mean to be a great product manager?

Cameron Adams gives a great headline overview of what it means to him.

1. Be a great editor.

Engineering. Research. Analytical. Design.

How do you work well with those who have deep domain knowledge in the areas you seek? How do you amplify their unique expertise and skillbase?

2. Low-fi. Any-fi.

The strategy you set up feeds into strategy and design and testing. Then it starts again when you iterate. It’s critical that what you set up sets the scene for all the decisions further down the line. Every step down that line increases the cost of what you’re building.

As your product progresses from sketch to design to engineering, the costs increase 10X.

Process: Google Daydream (VR Platform). In attempting to explain VR technology was really hard as they didn’t have a prototype. So the designer wrote a story about what it would be like, the experience of virtual reality, 5 years down the track. Google used this vision document to lead design and decisions for the next 5 years. Likewise, Amazon wrote the press release before they’d done anything else.

Jump point. What is the story of what this idea looks like when it’s working? How does it change the market? What does it feel like to use it? What is the customer story of what life is like for them with this idea as it’s working?

Sketching is a critical way to conceptualise and communicate ideas to a team.

UI Collaging. You can take parts of your UI and other people’s UI and mash them up together. Taking common patterns from tech or design cues or idea trends that already exist, and creating a new product.

Which products need a physical prototype to understand the full experience? And which can be built off the back of a napkin?

3. Different products / different teams.

A product that runs on the command line versus a mobile platform that is heavy on the UI, requires different skill sets. Understanding which teams you need is critical. Not just back end versus front but . . what sort of front ender do you need? Who is the right person to go on this journey with you? Are they a front ender into coding for data visualisation? Have they been doing a lot with REACT lately? maybe they’re the person to lead your UI KIP project.

4. Harness your naivete.

It’s not your job to stand toe to toe with the best engineers and designers and UI experts in the room. As an expert in the field, your domain expertise is built up on previous experience, reading about things, studying things, being involved in a lot of things previously, . . all this knowledge comes into how you perform your craft.

An “expert” engineer sees a problem and pattern matches it against what they’ve done or seen before, what they’ve seen other people do before. What they’ve been wanting to try or have seen others try.

As an outsider without the intricate knowledge and expertise, you’re able to break down those patterns. If you can get an engineer to explain their solution step by step, you can often approach the problem differently. This can be critical in breaking down patterns that will stop you from moving faster, stop you from making the right decisions or taking a different route.

This can be the difference between an 80-90% solution, and a 100% solution. This doesn’t apply to everything and every decision, but there are times when this can be the difference between something good, and something incredible. It might feel small in the moment and it might feel small to the engineer in that conversation; but the trick lies in perceiving those pivotal decisions or design shifts or UI adjustments and knowing when to step back and reframe with the team.

5. Hack. hack a lot.

Two solutions can be the right way.

Another solution can be the fast way to do something.

In the beginning with a startup, when you’re looking at building a product, learning about the product, learning about the customers and the market and product delivery . . sometimes the fast way of doing something is actually the right way of doing something when it comes to product delivery.

Productivity booster – how can you hack different short cuts of doing things? How can you apply creative problem solving to the problems that are presented to you in an ordinary everyday product development process? Hacking doesn’t have to be technical hacking. It could be from a marketing, delivery or distribution POV to solve the problem.

How might you rapidly inject some java script into someone else’s product to rapidly test a new UI idea?

As a non-techie you could get a spreadsheet and use an online API to pull some data from your support centre to find insights into your product.

6. Build Trust

When you’re working in a product team you don’t always have a lot of power of these individuals. You need to build trust and take them on that journey.

Expertise. It’s your job to intimately understand the product you’re creating, the problem you’re solving, the market you’re entering into, the solutions you’re proposing. Research, prototyping, analysing. Figuring out how it’s all going to come together is your expertise. Get them to come on board with your vision for the product.

Empathy with your team mates as human beings. They are not a resource, they are a team of partners walking on this journey with you.

Privacy Preference Center

%d bloggers like this: