I recently wrote about the values I keep in mind when building products and product teams. While those are quite clear, figuring out the best way to apply those values requires constant attention. Recently, my team of product managers and designers found themselves reassessing how we talk about product efforts with people outside of our group. Changing the format, cadence, and attendees were all on the table. Our goal was to improve collaboration, understanding, and overall “product culture.” This was an opportunity for experimentation.
So, what’s the problem?
When reviewing product progress with stakeholders and executives, our conversations tended to focus more on tactical execution, and implementation details. My team and I saw a big problem with this: we felt we were talking about all the wrong things. These types of conversations certainly have their place, but if you subscribe to the notion that product managers and designers primarily live in a world of product discovery, that means there were more important things to discuss with executives and stakeholders:
- Do we understand who the customer is?
- Do we understand their problem?
- Are we learning at a fast enough rate, and ultimately iterating towards a solution that’s valuable, usable, and feasible?
As product managers and designers, we felt these were the more critical questions to be asking during a product discovery process. We didn’t want to just ask these questions of ourselves, we wanted everyone else to be asking us.
A better approach
We decided on a weekly catch-up session with a representative from each area of the company as a pilot group (with a goal of eventually opening up to anyone that wanted to observe). They’d be short, with careful consideration for the language we used, and how we framed the conversation. We thought if we kept things basic yet consistent, the message would better sink in over time.
We’d try to get past any pent up anxiety right away by spending the first 15 minutes (with a strict time box) answering any general questions. Sometimes the answer would be “let’s revisit that at the end,” but at least this way everyone knew what nagging questions might be hanging out there. From there, we’d follow a simple format and have everyone write down their questions rather than interrupting. This ensured that we covered the breadth of what was important, and avoid getting into runaway discussions prior to equipping people with the necessary data.
Our format looked like this:
- State your hypothesis. Set the stage by explaining what the goals were for the previous week. Not everyone will be living and breathing this stuff every day like you, so it’s helpful to bring them up to speed in a sentence or two. Often we’ll say: “We believe by providing [some user with a particular problem] with [some proposed solution], it’ll result in [some meaningful value for the user] as measured by [a specific success metric].” That last part is particularly important. It focuses everyone’s attention on the outcomes, rather than the details of the UI design.
- Demo your prototype. I use the term “prototype” loosely here, but this could be anything. Whatever you built to test your hypothesis. It could be a paper sketch, a business canvas, a survey, a Keynote presentation, or (of course) working software.
- Describe your experiment and what you learned. Tell everyone who you tested your prototype with and how they reacted. For example: “We showed this prototype to 5 customers, and a handful of internal people over the last week, and here’s what they said…” This is important and where a culture focused on learning should be placing emphasis. Its lays the groundwork for the decisions you’re about to share; it informs the feedback you’re about to hear.
- Propose next steps & discuss. Let everyone know what the team thinks it should do next. Then, open things up for feedback and discussion with what time was left.
These 4 steps should take no more than 15 minutes for any given project. If you’re meeting weekly, 15 minutes is plenty. If you feel there’s more going on than can be covered in that time, focus. Pick the most interesting thing you can discuss from the last week and talk about that. Right now, we’re more interested in building good product design muscles, not a thorough analysis of every decision made.
Does it work?
The first time we tried this, people were thrown off. Team leads ran out of time (in which case, we literally just cut them off). Stakeholders were frustrated, feeling we weren’t covering the things they felt important. It was unclear whether having rules around when people could interrupt was actually helping collaboration or hurting it. It was rough, awkward, and unsettling.
After a couple more times through it though, things seemed to turn a corner. The reviews became smooth and concise. People of other groups became more engaged than they had in the past. They began asking the right questions, and didn’t seem as concerned about details of the UI. We’d hear things like, “Well, what did our customers say about that idea?” or “If that’s how they felt, I understand why we needed to change this.” It was clear they were genuinely excited to see us improving the product by learning directly from our customers. These were all things we were thrilled to see happening, and we were impressed by how some simple framing and consistency could have such an impact on people’s behavior over time.
We think we’re on to something here, and will continue to experiment with variations of this. Culture change is hard, and the jury’s still out on whether this approach truly gets people more focused on “learning” in their daily work. However, I feel like you can measure the impact of change by paying close attention to the words people start to use. Even more importantly, you can pay attention to the types of questions people ask. If that’s true, we’re seeing a strong signal that we’re headed in the right direction.