Lean Product Management on a DIME
While setting up my team to use Lean practices at OpenSky and Conductor, I had a hard time figuring out exactly what the role of a Product Manager was on the team. I knew that I was still in charge of the vision of the product, and thinking about where we would take it in the future. But, the main function of my job – coming up with what to build – was now something the whole team contributed to. Then there was the speccing, something that took up 80% of my day. Lean and Agile practice collaboration over documentation, so what happens to those documents I had been making? What exactly is a Lean Product Manager responsible for on a day to day basis? I’ve found the daily role of Product Managers shifts away from churning out solutions and specs, and into that of a facilitator and team-leader. I became responsible for setting up the experiment, empowering the team to solve problems, and making the hard definitive calls, all while steering the vision of the product. In my class, I call this process DIME because it’s easy to remember:
- Define the problem
- Investigate assumptions
- Measure results
- Evaluate success
Defining the Problem:
Product Managers bring the problem to the team and rally them around it. They are responsible for explaining why it is important to solve the problem, how customers are experiencing problems now, and what their potential solutions could mean for the company. When I have the original kickoff meeting with my developers, I try to tell them a good story about the problem. I get pretty dramatic for emphasis. (Thanks High School drama club.) The better story you tell, the more everyone gets excited about what you are going to build. Driving passion in the team to solve the problem is one of the most important jobs a PM can do.
Investigate Assumptions:
When we’re talking about the problem, I’ll use that meeting with my developers to talk about our assumptions. We’ll discuss how we believe the users interact with our product now, what we believe they do in their daily jobs, and other things we’re not sure about. After the team lists their assumptions on sticky notes, I’ll the charge to explore if these are correct or not. I always include my developers in this discovery process, so they hear first hand what the customer is saying. This makes them feel closer to the problem and gets them excited about coming up with the solution.
Measure Results:
Every problem that is getting solved should be tied to a KPI. The PM figures out what data to collect during the experiment, and then tracks it. I talk to the upper level management to figure out what are our business’s key goals for this feature. Do they want to see higher revenue? Do they want to increase engagement? What is it about this feature that will change our business as we know it today. Metrics can drive so much insight to help your decision making in a startup, but you’d be surprised how many companies have none implemented.
Evaluate Success:
Finally, I reflect on my feature experiments and decide whether it was successful or not. This can be a hard call to make. Sometimes the data is juuuust off the marks you wanted to hit. Sometimes everything is a complete flop and you’re not even sure where you went wrong. It’s up to the PM to lead the discussion with the team and make the ultimate call around the success of your project. If it failed, I’ll investigate the cause of the failure to determine the next move, usually by talking to customers. If it succeeded, I will drive the initiative to build out a full product (remember an MVP is only a test!)
When you work in small teams, everyone wears many hats. Sometimes it can seem a bit chaotic, and you’re not sure who is in charge of what on a daily basis. It’s important to have guidelines on who is in charge of certain aspects of the development cycle so they can lead the discussion around decisions and make the calls in time of dissent. Using DIME has helped me define my day to day job as a Product Manager in a Lean team, while keeping our teams balanced and focused on the vision.
