A Letter to Devs: What to Expect from Product Managers
Developers and Product Managers work closely together and the expectation from each one of them can be made clear. I will attempt to shed some light on that.
Product management as a profession has had different names throughout our recent history and building it into a professional career has become more prevalent in the tech industry. For many, the role of a product manager sounds a lot like a project manager so it may get confusing as you hear these titles thrown around assuming everyone is aware of the framework. I will attempt to highlight the note
A product manager (PM) needs to do 2 things very well (the meat and potatoes of product management):
Figure out the next most valuable thing to build (with emphasis on “next” since building is an iterative process)
Be the source of clarity for the dev team (must be clear on the vision and value. In addition to being able to make decisions quickly)
As a dev, you are probably one of the smartest people on the team and you should be able to get indicators that show the product managers were able to do the 2 things above well. If they do #1 well, they should be able to show you outcome-driven metrics to show that the users using the product actually see value and that’s captured through their behavior. If they do #2 well, you should feel that you have a clear idea of what you need to do in addition to being able to get clear answers + decisions quickly.
That is it.
Now, if you are curious to understand more about the methodologies and thinking frameworks that product managers follow, please continue reading (I will do my best to make it concise so it is not a waste of your time).
For #1, PMs typically go through a “discovery” process that includes other people such as UX Researchers, UX Designers, and others (sometimes tech leads or devs). This discovery process is essentially the lab within which the needs of a specific segment of people/users are identified. The process is not a complete science but there is a methodology to follow (generally speaking). If you haven’t been a part of one, I’d encourage you to get involved (it is fun). The process follows 5 stages: Framing, Observation, Synthesis, Strategy, and Prototyping. It is very similar to how you’d build hypotheses to be validated in a lab before taking them to the world. I will go through each one of these stages briefly (please let me know if you find this helpful and I can expand in a future post):
Framing: this is essentially the prep stage which includes writing down all the questions that need to be answered through the discovery. For example, let’s assume we are launching a travel companion app for seniors (to illustrate the process). You may have a few questions such as:
What are the top 5 routes and locations seniors feel they need companions for?
Is the companion only needed for the duration of the flight/drive? Or is it beyond that?
Would this companion be someone who takes them on a guided tour in addition to being with them throughout the flight?
What are the top 5 things to help seniors with during the trip (packing, translation, etc)?
Would an app be a good idea or should it be a phone number to call?
And so on. The idea here is that you already have a hypothesis that there is a need in the market for a travel companion app for seniors but you are not 100% sure what it could be and whether or not it would truly be useful. This step of the process allows you to think through all of your riskiest hypotheses and questions so they are answered. The questions are shortlisted and a select group of people (your target customer) are identified so you can speak to them. In the past, we offered them a $50 gift card for 30-60 min of their time so we could interview them (in person or virtually). People love talking and if you’re extroverted, you will probably enjoy this a lot.
Observation: this stage is all about observing data. No conclusions, no judgment.. just observe. If you are doing interviews, the people you are interviewing are guided through a series of things to react to and provide their opinions. The key thing here is to not lead the witness and keep the questions open-ended. For example, we start by describing a scenario where an English-speaking senior has to travel to Japan to attend their grandkid’s wedding. They don’t speak Japanese and they feel nervous about traveling alone. We would ask the interviewee, if that was you, how would you feel? They start talking and when they stop or say something that feels interesting, you’d ask them by keeping it open-ended such as “You mentioned that it makes you feel very nervous to go on a flight that is 8+ hours long, tell me more about that.”. The idea is to keep them talking and get to observe and document as much as you can. UX Researchers are great at this! Interviewing 8-16 typically gives you enough data to work with.
Another type of observation is looking at data and trends within that. The same concept holds, you observe and write down your observations.Synthesis: this step is cognitively taxing but it can be fun if done in a group (in person tends to be good but can be done virtually too with some tools like Miro). This is the step where you take all the data you observed and start sorting them into patterns. These patterns are referred to as “Jobs-to-be-done” which is part of a very well-documented framework that focuses on the need rather than the solution (Google it, it is neat). The main idea here is to ground your findings into patterns so the solution you may build in the future does not address edge cases but rather patterns that are unlikely to change. Designing and building towards patterns that are not changing is key to anchoring your solution for long-term success (your work becomes no-regret work). First-principle thinking and questioning the need and human behavior are very essential to make sure this step is useful. I admit, this is by far the step that gets my brain working the most but the rigour and going through deep thinking pays off well.
Strategy: Now that you have some patterns identified and grounded by observations from actual humans, this is the time to think through how to build something that is “directionally” useful. You don’t have to fully solve the solution and how it scales, etc. This is a step to think through the guardrails within which you and the team will try to innovate (strategy is not a plan with a timeline. Strategy is the principles that apply to the users, market, and business goals so any solutions align with it). The most useful thing to do here is to try to summarize the entire strategy on a Lean Product Canvas. This canvas will force the team to answer all the questions that will be the “guardrails” or “Principles” so that the solutions proposed fit within it. Things like “What is your unfair advantage”. Why can’t someone else build a solution? Why is your team unique? Do you have a specific knowledge, ability, or access that gives you more leverage compared to another team with the same passion for the problem as you? The Product Canvas exercise can be done by each team member Individually (~20 to 40 mins) then you can combine your points into one.
Prototyping: this is the step where you think you have a couple of ideas on how to solve this problem and you can quickly build a prototype (in Figma or even on a piece of paper) so you can show it to some people from your target market (the people who will ultimately use the solution). The most famous way of doing it is going through a “Design Sprint” which is most popularized by Google. Think through 2-3 solutions, draft/prototype them, and show them to your target customers. The prototypes typically look ugly or lo-fi but that’s a part of the process. No point in spending the time to build more detailed prototypes if you are still not sure it’ll truly solve the problem/need.
The output of this process is essentially how you feed your product backlog with items that are likely to be the next most valuable thing to build. It is like an insurance policy so you’re only writing code for things that are better bets on average to solve a true need in the market. Since software in nature is very malleable, you need something to ground the thinking. Otherwise, the team will build a lot of software and you most likely will get no usage. The example I used was a 0 to 1 product (i.e. no product at all to some product that has the potential of product-market fit) but this can be applied to products going from 1 to 100. This cycle can take 6 weeks or can take 2 weeks. As long as you go through the steps, you’re essentially doing discovery. A lot of companies skip discovery and they instead just build based on “hunches”. However, that’s like betting in a casino blindly. You may win but the probability is that you will lose all of your money by the end of the night. The outcome of discovery may be “yes, there is a signal that we should move forward with this” or “our hypothesis is false because we discovered that <insert a finding>. So we should not be writing any code and will do another cycle of discovery”.
Okay, now let’s go to #2. Once there are “tested” prototypes and concepts that are grounded by the process I mentioned above, the backlog is probably getting stories + epics to be built. This is now the “delivery” cycle during which you build stuff / write code. This is the part that most people are familiar with. A good PM can be a source of clarity for the team. They may create diagrams, write stories, etc. to illustrate the concepts and what is attempted to be solved here. The PM in this cycle essentially wears the “Product Owner” hat if you are following the agile scrum framework. In addition to creating clear requirements and stories, the PM during this cycle is managing a lot of opinionated stakeholders (people who are telling them what to build and when. It can be sales folks because they oversold something or the CEO because they read a cool article saying that you should build LLMs now). The management of stakeholders is more of an art but a good PM is like a diplomat (manages expectations without pissing off any important stakeholders). Once you’ve built some scope of the product, it comes time to actually ship it to the world and see if people adopt it or not (maybe with some iterations). The go-to-market is tricky but the PM would work with Product Marketing to get this to market via the appropriate channels (please note that I am skipping details on this). You will start to get usage (i.e. number of users, total # of transactions, a specific page/photo/video views, etc.). The PM should (I’d argue, must) be able to start presenting these numbers to the team and start talking about the “outcome” of the work the team contributed to. It is an answer to “Okay, we did all of this work. So what?”. Discovery was done to make sure the bets/software shipped is more likely to be used, the product was built with clarity, and the go-to-market was executed well. Now it is up to the target customers to react to the product that is available in the market and competes with other alternatives. Do you see people using it? Yes, great! Quantify that and let’s discuss how that can be improved. No? Alright, what did we get wrong? Let’s address that before adding any more code or we might potentially need to shut the product down.
I am sure the product you are working on has more intricacies that I didn’t capture but the overall process can still be used. Iterative product development is frustrating at times but it is gratifying once you see people using something you and the team created from thin air (a big reason why I love software).
In summary, a good PM should show you why something you are being asked to build is valuable for the world. If it is not clear, bug them to give you more details and help you understand. Why would you work on something that you are not sure will help anyone else on the receiving end? I get that you are being paid to build/write code but I’d highly encourage you to ask your PMs the reason why .. what makes you believe that this will be useful? Or if you already shipped a product, ask them to show you and the team the quantifiable metrics to show the usefulness. In fact, you asking may even help them tighten up their understanding too.
Alright .. thanks for reading.