(Customers Rule Everything Around Me)
Are you listening to your customers? Cool, listen more. It’s common knowledge that as a Product Manager you must be customer obsessed. The customer is the starting point for Product Managers. This is especially true in a startup environment where you often have to work backwards by starting with the customer.
Marty Cagan says it best, “the best product teams solve hard problems in ways their customers love, yet work for their business”. To make sure the customers love the product, a lot of time has to be dedicated to understanding the customer. If you are not listening to your customer enough, you end up creating solutions for problems the customers don’t have.
Here are some of the things I have learned:
- Listen to your customer to understand the problem, stop listening when they tell you the solution
- As a Product Manager you should be coming up with a solution the customers love
- Great products are often a byproduct of intense collaboration between product, design and engineering to come up with a solution that customers love and makes sense for the business
- Dig deep when interviewing customers
- It’s easy for customers to be general when having a conversation, so don’t be afraid to ask follow up questions
- For example a customer might say “I play a lot of basketball” when in reality they play basketball every other month
- Use quantitative analysis to see the ‘What” and then qualitative analysis to see the “Why”
- You can use quantitative data to get an overall picture and dig deeper with qualitative data
- For example: You notice that you have an unusually high number of users in a specific region. You then conduct a user study for that region and notice that your product is solving a unique problem you never thought about
- Get customer feedback on Prototypes
- Demoing prototypes with customers can lead to a gold mine of valuable data
- “Sprint” by Jake Knapp and the GV team has a great framework for conducting user interviews with Prototypes. If you haven’t already picked it up, you should. Even if you don’t plan on using the framework, it’s a treasure trove of validated models like this one: (The 5 act interview)
- Friendly welcome: Create comfort with the customer
- Context questions: Ask questions about the problem you are trying to solve
- Introduce the prototype: Let the user know you did not design it, and nothing they say will hurt or flatter you
- Tasks: Have some tasks available to understand some lingering questions
- Quick debrief: Talk about some of the things you observed, and use it as an opportunity to ask any follow up questions to gauge what they like/didn’t like
- Break feedback down into actionable themes
- Sometimes you can be bombarded with a ton of feedback from customers from all over the place, and it’s important to break it down into common themes
- Breaking feedback down in to specific themes allows you to make sense of it all, and dig a little deeper in to what the problem is (this is a great opportunity to use the 5 “whys”)
- You will hear negative feedback, don’t get defensive
- It’s human nature to be married to your product and the decisions that you made
- Negative feedback is the most valuable feedback because that’s what you need to improve your product
- Leave your ego at home!
Get out and talk to users. You want to be able to empathise with the customer. The great thing is, they are always willing to talk and provide feedback and should be a regular part of your discovery process.
I know there is a lot that I have missed. If you have any other methods to get to know your customer better, comment below and start a conversation!
Wodtke takes a unique approach to explaining OKRs in “Radical Focus”. This book is unique due to that it’s written as what can be called a business novel. It’s part fable, part autobiography and part business manual. Even though the approach isn’t the most conventional, I found the insights and framework provided valuable for anyone planning on using OKRs across an organization.
This book is a great compliment to John Doerr’s, “Measure What Matters”. Wodtke takes a bit of a deeper dive in to real world scenarios with OKRs. Doerr shows how OKRs have worked, Wodtke shows how OKRs won’t work.
What makes this book stand out for me is the chapter that’s specific to OKRs for Product Teams written by Marty Cagan. If you find yourself not feeling the business novel based approach and want to put the book down, skip to chapter 10 before you do so.
A few key takeaways are:
- Don’t leave out department and individual OKRs
- Although Product Team OKRs are the highest priority, it’s important to collaborate with the squad to prioritize department and individual OKRs as well
- Set a pace that makes sense
- Keep your OKRs time-bound, but be cautious of making it too long
- Typically OKRs are set per quarter, but do what makes sense for your team and business
- Keep it simple for better focus
- At an organizational level aim to have only one OKR per quarter
- Having too many OKRs per quarter will cause teams to fire in all directions
- Make some “Big Hairy Audacious Key Results”
- Key results are meant to be aspirational
- It’s ok to be uncomfortable with the key results, as a matter of fact it’s recommended to be 50% confident when setting key results
- The purpose is that you want to make sure that even if you don’t hit the target, getting close will still be a big win (don’t forget to celebrate those wins!)
- Don’t have a metric driven objective
- Aim to inspire with your objective, and focusing on a metric isn’t very inspirational
- Track confidence and adjust accordingly
- If a key result no longer makes sense, change it
- Be patient
- OKRs won’t be perfect the first time around
- Be agile, experiment and make adjustments till it works
- Communication is key
- Aim to have at least 3 team wide communications for OKRs
- Friday meetings for celebrating wins
- Monday meetings for status updates
- Weekly emails with wins, statuses, blockers and confidence
Overall this was a very insightful look into some suggestions for implementing OKRs. It’s a pretty quick read, so if you got a few hours definitely pick this up.
A lot of risk exists when releasing a new product or feature. Even the best product organizations get it wrong sometimes. Remember the Amazon Fire Phone, Netflix launching Qwikster, Facebook Deals, the original Apple Maps app and the graveyard of failed Google products?
The thing is, product is hard. The smartest leaders are well aware that the majority of launches will not have a positive ROI. That’s one of the reasons why Agile is so important, so you can learn fast and make improvements iteratively.
One way to improve your chances of success is to collaborate with engineering, design and stakeholders to mitigate against the four major risks:
- Usability Risk: Is it intuitive? Will the users figure out how to use it?
- The designer is responsible for assessing the usability risk.
- This is the designers opportunity to create some high fidelity or low fidelity prototypes to share with the team.
- Feasibility Risk: Can we build it? Do we have the tech, time and skills required?
- The engineers are responsible for assessing the feasibility risk. It’s important to get the engineers involved early to determine feasibility.
- This is the engineers opportunity to build a feasibility prototype to test things like algorithm changes or performance issues.
- Business Viability Risk: Does it make sense for the business?
- The PM is responsible for determining the business viability risk.
- This where the PMs intimate knowledge of the business, industry, customer and data come in to play. This is where as a PM you have to decide on what the ROI is going to look like, and if it’s even worth it.
- Value Risk: Will the customers buy it? Will the users use it?
- The PM is responsible for evaluating the value as well.
- This isn’t necessarily the same as the usability risk. Think of the value risk as a combination of usability, feasibility and viability.
If you haven’t noticed already, collaborating with your team to determine risks is highly reliant on creating prototypes. Prototypes are a great way to get the team around something that they can touch and feel to discuss and get feedback. I have written about some of the different types of prototypes that can be used to collaborate here.
At the core, a product manager is responsible for bringing together 3 things: Customers, Business and Technology. You have to be deeply customer centric, obsessing over data and having an intimate knowledge of your users. You must collaborate across your organization to have a solid understanding of your business model, the competitive landscape, core competencies and strategic vision. You must also understand the technology, along with its capabilities and limitations.
Devs are your ultimate resource, not only for technical feasibility but also ideation and discovery. There is a reason why the most common path to Product is via Engineering. In my experience some of the best ideas have come from the engineers.
Devs are just as passionate about the business, the product and the user as the Product team. Devs are also very keen on customer wants and their pain points. So it’s only natural for devs to get excited about discovery and solving user and business pain points.
Get your devs involved early and often. Ideally the dev team will be fully aware of what the teams OKRs are for that sprint, month, quarter etc. When discovery starts, the PM and the dev team should know:
- What the business objective is
- The problem that you are solving for
- Who the user is
- What success will look like
At the very least, the technical lead in your squad should be someone who is involved early and often. If the first time the devs are able to discuss a product or feature is during refinement or planning you are most likely missing out a ton of valuable insight. The key is to be missionaries not mercenaries, and collaboration between PMs and devs is key to creating missionaries.
I was at a PM meetup recently and a lot of questions came up about prototyping. The questions were mostly about when you can and can’t use prototypes. The thing is, you should always be prototyping. Discovery is all about testing hypothesis using prototypes. Adding a new page to you application flow? Prototype it. Adding a store locator? Prototype it. Collecting a new data point? Prototype it. Want to add free tacos at checkout to increase conversions (sorry i’m hungry), prototype it. You get the point.
You should aim to have your tech lead or engineers looking at prototypes daily. I know that sounds hard, but just 30 minutes a day looking at a prototype can go a long way. The most expensive prototype is the one that the engineers build to cover every use case, takes a sprint or two and then gets pushed to production to be A/B tested. The point of a prototype is to learn fast and cheap, and if you already spent a sprint building something than it defeats the whole purpose. This is one example of what Paul Graham means when he says, “Build things that don’t scale”.
Now there are a few different types of prototypes you can use when you are in discovery.
- Feasibility Prototypes
- These are used to determine technical feasibility risks. Feasibility prototypes are typically created if engineers identify a risk with performance, algorithm, fault tolerance, scalability, new technology, legacy systems, or a third party. The code should be quick and dirty and intended to be thrown way, so don’t worry about UI or error handling.
- A feasibility prototype will help mitigate against the risk of grossly underestimating or overestimating the amount of work that would need to occur.
- User Prototypes
- These are what most PMs are used to. User prototypes are usually wireframes made with software like Balsamiq, Sketch or Invision and come in two forms:
- Low-Fidelity Prototypes which are used to gauge the information or the workflow. Low fidelity prototypes are wireframes sketched out on paper or using software like Balsamiq to create rough sketches.
- High-Fidelity Prototypes are wireframes that look and feel like the real thing. They are interactive and the user will typically not be able to tell the difference. Often these are made with Sketch or InVision.
- Live Data Prototypes
- Used to collect actual data to see if we can prove a hypothesis or gather enough data to support one. Live data prototypes need to have access to live data sources and be able to send enough live traffic to test the hypothesis. The prototypes are typically used for work flows, new designs or features.
- Some examples for use are for applying game dynamics, product funnel, or search result relevance. You will use a live data prototype to collect data on how the new approach performs.
- Hybrid Prototypes
- These are a combination of the above. An example of a hybrid prototype would be one that combines a high-fidelity user prototype, but having a live person taking care of back-end processes that would be automated in the shipped product. An example would be a lead gen application funnel, where the live data is collected from the user but then a person will manually submit the leads.
The important thing to remember for all these approaches is to keep it simple. Prototypes are intended to be thrown away, and not scaled. You don’t want to waste designers or engineers time building something that will be thrown out. These are justs tests to see if a hypothesis is valid. There is no point in building something flushed out that might not even see the light of day.
Happy Discovery! Time for me to get some tacos 🌮
New and seasoned PMs all too often find roles that are pitched as Product Management roles, but in reality they are nowhere near an actual PM role. We have all seen it, the job post with the title “Product Manager” followed by a description that resembles something similar to a Project Manager or Product Owner. Sometimes the description is spot on but after a little digging you find out that the role isn’t a true PM role. It seems as if a lot of companies today just see “Product Manager” as some new hip term that is used to describe the person who “talks to the engineers” without realizing what the responsibilities of a PM are, let alone the value that a truly great PM can add.
The reality is, unless you are going to a company that is famously product driven or a FAANG, it can be hard to tell. The danger comes in getting yourself stuck in one of these roles. A move in to one of these roles could be a great learning experience, but will probably stunt your growth as a PM.
What you need to look for is joining a company as a Product Manager on an Empowered Product Team. Marty Cagan describes Empowered Product Teams as:
“cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.”
That’s why interviewing is so important because it’s your opportunity to determine if the company is looking for a true Product Manager, or something that they think is a Product Manager. I like to ask these questions when interviewing to gauge companies:
- How are the teams structured?
- This will let you see how the PM role is utilized, either within a scrum team or as a separate entity. You want to make sure the PM is embedded within the team or squad.
- This is also an opportunity to see if you will have data or design resources in your squad (because if you don’t, the responsibility will probably be on you).
- How large is the Product Team?
- You want to be wary of places that have a lot of Product resources when compared to engineers. A typical scrum team is between 5-8 people, so if a company has a 15 engineers and 5 Product Managers I would be concerned. Too many PMs could mean that PMs would have to battle each other for engineering resources, and likely function more as Project Managers.
- What’s the current backlog look like?
- This is a tricky question that can reveal a lot. First of all if there is no backlog at all, that’s good because it means that it’s up to you to fill it up. If it’s up to you and the squad to create and prioritize the backlog, that usually means you are a part of an empowered team.
- If a backlog already exists, that isn’t a bad thing either. If the product isn’t brand new, you can expect features to have been designed and prioritized prior to your arrival. However, this is your opportunity to find if it’s your responsibility to fill and prioritize the backlog. If filling and prioritizing the backlog someone else’s responsibility, then they are looking for a Project Manager or Product Owner.
- How are the teams measured?
- This will let you know if the teams are measured on outcomes, rather than output.
- Often times empowered teams are measured by an OKR, typically quarterly.
I also like to look at the current PMs on staff, and the VP/Director/whoever is leading the product team. If they come from a FAANG or product driven org, they are most likely operating or building empowered product teams.
Keep in-mind that you shouldn’t write off a company simply because they are not empowered. Building empowered teams requires a lot of resources, and a lot of trust. Younger companies that have a product minded founder or co-founder are most likely not going to be empowered. Working hand in hand with a co-founder in a Product role can be an amazing opportunity for a PM.
Hi, I’m Sam Mogharabi. I have worked in Software Development since 2009 and have been working in Product since 2014. I have worked for “big-tech” and for small start-ups.
This blog focuses on the day in and day out of the life of a Product Manager. From discovery to deployment… and everything in between (yes I know, success criteria is after deployment but I liked the way it sounded).