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.

Lean UX NYC Recap

When Will asked me to speak at Lean UX NYC on Lean Product Management, I was both excited and confused. It didn’t make sense. This was a UX design conference, what would he want with PMs?

When the first day of the conference was over, no one thought it was just a UX design conference. There were speakers on every section of the business. Johanna Kollman talked about how lean makes learning the new deliverable for design consultants. Adrian Howard explained that the lean process is actually brand discovery for startups. Bill Beard spoke on how copy should be integrated into Lean UX to enhance the user experience rather than be used as a crutch. Grace Ng showed how UX designers can leverage the concierge method to do Minimum Viable UX before designing the whole product. Tomer Sharon gave user research tips for engineers: “Watch what the user is doing, instead of asking the user what they need.”

Throughout this whole conference there was one major theme: collaboration. The reason lean is so powerful is that it incorporates the entire team in solution generation. There is no longer a product “owner”. Virginia Cagwin talked about how you need to break down the silos in typical enterprise businesses and form balanced teams to produce sexy ideas. This is a huge culture change that is very hard for waterfall companies to understand and adopt, but it can be done. Ari Font Llitos showed how they do this at IBM by creating these small teams, and then teaching them design thinking.

Now once we have those small, balanced teams, the question becomes what process do we follow? Jonathan Berger brought up great points about creating sustainable pace for designers when working with agile development teams. Designers have been asked to work at the fast paced tempo of developers’ sprint cycles, which leaves them feeling overwhelmed and disempowered. Lane Halley and Courtney Hemphill spoke about how they are practicing ways that can help solve this problem at Carbon 5. They practice short, weeklong sprints that run through the build-measure-learn loop. The whole team participates in discovery, building, and testing during the sprint, eliminating the need for extensive documentation and designs. I think what made this talk even more powerful was hearing Courtney, a developer, endorse the integration of LeanUX into the agile workflow.

Will Evans wrapped up the conference with a great talk on modeling leadership. What really resonated with me was his call for creating a shared language for new processes rather than trying to distort the language of older processes to fit a model they don’t belong to. Designers and developers are subject to using industry jargon that doesn’t make sense to people outside those roles. Being able to effectively communicate with team members aligns everyone around a common goal. I picked up ways to communicate through two workshops last weekend. Jacklyn Burgan’s workshop on “Sketch Before You Etch” taught me a way to generate ideas with my team through simple sketches, something everyone can relate to. Lane and Courtney’s workshop on “Conversation, Cadence, and Culture” simulated the conversations and language I should use when sketching and building with the team. I just started working with a much larger development team, and effective communication has been a challenge for us. I’ve already started integrating these techniques in our new project and I’m seeing great results in just a week.

By Saturday, everyone from doctors to developers had given a talk. In fact, we could all probably form our own lean startup and make kickass products without needing to fill any roles. I realized now why the name of the conference makes sense. That’s what UX is: User Experience. It’s all the pieces of the business working together to make a unique, compelling experience for the people who use your product.

This is the first conference I’ve attended where people are still talking about it a week later, which only goes to show you just how much useful information came out of it. I’m still pumped. I met so many wonderful people last weekend, and I’m still riding the high of it. Balanced Team brunch with the speakers was just icing on the cake the next day, and I can’t wait to do it again soon. Thank you Will, for including me in an epic weekend.

If you did not go this year, make sure you check it out next year (it’s already posted). The sheer amount of knowledge you’ll walk away with is well worth the ticket price and will continue to help you for years. I’ll be there, mumbling my speech to myself and shoving macaroons in my face. You can find me by the cookie table.