Laura Oppenheimer

Part of the fun of building something 0-1 is that you have a green field in front of you — you can build anything! (Or that's what we wish as PMS....)

As much fun as it would be to the world is your product oyster, constraints help provide focus and a direction. I see the first step is making sure that you and stakeholders are aligned on what a goal or success looks like. And usually, that comes in the form of a metric that you're trying to move. 

If you work for an ecommerce company, you'll make very different decisions around what to build if your metric is increasing ASP versus unlocking a new vertical or segment. If your metric was the former, you might start doing user research on customer willingness to pay, or what they're thinking about when they're in the check-out flow. And if it's the latter, you'd probably start with user research into people who aren't yet your customers. 

Without that first constraint — what metric do we want to move, what does success look like — there's no way to focus your research and problem defintion phase. Once you have that north star to work toward, you can enter user research with your specific goal in mind. 

So much about product management is about stakeholder management — getting everyone from engineers to exec team aligned on 1) what you are building and 2) what the goal is. With goals, we're very good at getting folks excited about the metrics-based goals ("we'll move conversion rate by 2 percent" or "sessions per month will increase by 10%") but I've found that it can be super helpful to align on what the goal is of launching something as well. 

At Quizlet, we've been very deliberate about defining (before we launch!) if the goal of our launch is to get signal on a problem space, optmize a product to move metrics, or if it's a longer term investment. Making those distinctions up front and getting everyone aligned on them is super helpful. 

For example, you may have high conviction on the problem, but you aren't quite sure if your solution is the right one. Launching a test of your product to get signal can give you confidence that you're on the right track, or give you enough data to go back to the drawing board and ID where your hypothesis wasn't quite right. Often those signal tests might be a little more on the Reed Hoffman embarassing side, and that's ok! If your stakeholders are anxious, getting them aligned that the launch is about getting learnings and de-risking the project should help! 

I might even abstract this out further to answer "What are the top mistakes product managers make when building a product period?"

The best advice I've been given — and what I try to follow in my own work — is to be obsessed with the problem and not the solution. It can be really easy to think you know what the answer is based on what a user tells you in research, what a PMM counterpart reports back or what sales is saying the customer wants. Solutions are sexy and it's fun to build! And yet, being obsessed with the solution is less important than making sure you're 100% sure what the problem is. 

Great question that goes beyond product strategy and into larger company strategy. Every product serves a given user job or jobs. When you have product market fit and things are going well, you then have a choice: 

1. Continue investing in serving the original job to gain a larger piece of the total addressable market for that job or:
2. Think about a new product offering that could either serve your existing customer in new ways or create a new adjacent customer segement to your original one. 

I don't believe there's a hard and fast rule here, but speaking with users can help shed light on whether your current product is "good enough" or if it still needs work. With every product, your users or customers will have feedback, and the question you need to answer as a PM is "Is addressing this feedback going to drive more adoption or usage, or is it a nice to have?" 

Frameworks like the RICE framework developed out of Intercom (or even an Impact/Effort 2x2 matrix) can help answer this question. From there, you can ID if the feedback you're hearing is feedback that will unlock growth in your current product... and if you don't think it will, you can look to build something new. 

After 2.5 years into working remotely, the two areas that have been the most challenging for me are 1) cross functional exploration and ideation and 2) user research outside of video interviews. 

First, I've found it really challenging to replicate is the ability to get in a room with design, engineering and PMM partners and think through problems and solutions to those problems. Whiteboarding and brainstorming are frequently thought of as startup cliches, but there's something really powerful about getting smart folks in a room to deeply grapple with a challenging problem. 

Tools like Figma and Miro can help (I've been so impressed with Figjam and how important it's become to my workflow!) but it's still so challenging to get folks to commit, distraction-free, to online collaborative project time. Slack, emails, pets, kids — it's all a distraction. This challenge most frequently arises during the ideation phase of "how might we address this [agreed upon] job to be done?"

Secondly, and much more tactically for my role at Quizlet in particular, is limitations on observing and interviewing users in the field. My customer is one who works in a particularly challenging environment in COVID world — teachers! Prior to COVID, we used to go into the classroom and see how teachers used Quizlet with their students. I'd make a point to do this activity outside of the Bay Area and visited classrooms in other parts of the U.S., and even internationally. This was an incredibly useful user research activity and I'd regularly learn new things about the problems teachers faced, and where Quizlet could be useful. Due to COVID, we haven't been able to spend time in the classroom and so user research has become much more clinical, with video interviews one-on-one (i.e. no visibility into the student side). 

While Quizlet is certainly used directly by students, my focus area has been teachers. For a product where the "buyer" (teachers) may not be the end user (students), solving for only the buyer needs without understanding more about how the buyer and end user interact has been challenging. 

Abstracting that out more generally, I'd imagine that for many product managers, not being able to interview and observe users in the field is a big impediment. 

It's never going to be "as ready" as you want it to be. Because we don't work in a vacuum, the product is never built to 100% (I've never worked on anything where we had P2 requirements built into the product on launch day - it doesn't happen). There are three components that come together to ID when a product is ready to be shipped: 

1) Business needs: If you run an ecommerce product, then your product needs to be out for Black Friday and the holiday rush. Similarly if you work in fitness, January 1 is going to be a big day. Aligning on these key dates and deadlines with stakeholders up front is important. At Quizlet, we focus on the Back to School season, which we define as August 1 through mid September. As a result, we'll sometimes know that something needs to be live on a given date — and then we'll work around that business need to scope the project and/or add more resources as needed. 

2) User Jobs to be Done: I wrote in one of my other responses about being obsessed with problems. Once you're sure what the problem is, you can reframe it as a job to be done to focus. For Quizlet and the teacher products I worked on, this was "When I'm teaching my students, I want to keep them engaged and check for understanding, so that I can differentiate my teaching as needed." When you can take your MVP back to users and test it out, and verify that it's serving the job you've defined, you're ready to ship. 

3) Eng readiness: Especially with launching a new product, ensuring that your engineering partners are ready is key. This includes asking questions like "What happens if we're wildly successfully and this product is used by XX people overnight" and "Can we test our logging to make sure these key actions are being logged" etc. Moving from MVP/beta to a GA launch means knowng that your product can scale up as it gains traction and that you'll be able to measure and evaluate its success!

At the very beginning! It's so important to align on the why for any initiative. Why now? Why is it important? And a big part of that why is what the world will look like when you're ultimately very successful. To bring that to light, I usually define 1) a success metric -- the one thing we're going to focus on moving and 2) the health metrics -- what we need to watch to make sure that we aren't tanking another key metric with our project. 

The more invested you can get the folks you work with in what success looks like and why you're doing the project, the more buy-in you'll have. Never too early to talk about what the world looks like when you knock it out of the park!