*Recommendation:** Commit to a future recap of your product development initiative, and design the slides early in the process (leaving placeholders for the actual data)*

*Benefit:** Promote a learning mindset. Balance upfront planning with unbiased retrospective. Crease a sense of team ownership and pride. Drive a shared understanding of the initiative. Promote evidence driven development, even when the current strategy is more tilted towards the “feature factory”.*

The Opportunity

I’ve always enjoyed exercises like premortems, future backwards, and heaven and hell. These activities are great for exploring potential futures for an initiative, and using that information to guide the plan and approach. I was conducting a pre-mortem recently, and a senior engineer said something that hit me like a brick:

You know… when this is “done”, we will have moved on to the next thing. Sure we will have shipped something, but it will be anyone’s guess whether this actually worked. When do we answer that question? It just never seems to happen.I thought about this for a while. She was right.

We had done a half-dozen activities exploring catastrophic outcomes, heavenly future states, problem definition, problem exploration, and possible solutions. There was a “great deck” with an inspiring vision and lots of broad context. But the reality was that her team would be cycled on to new efforts before they had a chance to validate the expected impact. It was the epitome of upfront planning — not adaptive planning — and that sucked.

Those activities are great, but they are still front-loaded. I tentatively offered the following thought exercise:

It is three months after shipping. You may have moved on to something else, but you’re eager to figure out if this worked and that it drove the expected results. It’s nagging you. You’re curious. You schedule a talk to the whole engineering team (100+ individuals) to share your learnings. What do you present?I figured an intermediate step would be simply committing to compare the expected outcome to the actual outcome.

Something about this proposal clicked with the team. It had the effect of putting a stake in the ground. It was a commitment to learning, and presenting those learnings in public…not just when and if someone had time to “pull the numbers”. Summary: it worked. The approach caught on and upped the whole team’s game.

General Outline

Below I’ve provided a basic outline for the presentation. It’s nothing fancy, but you’d be amazed at how infrequently these types of presentations happen unless there’s a major win to promote. Learnings are rarely celebrated, and that is a shame.

Tips:

• Get executive buy-in for the retrospective, and schedule it early. Part of what makes this work is the excitement (and pressure) of presenting to the whole team
• Use a design studio approach to “design” the slides. This alone is a great exercise for driving a shared understanding of the problem to solve. Whenever possible do it with the whole team
• Use actual numbers whenever possible, but don’t be afraid to tell good stories
• You might need to arrange a data-foraging exercise to pull this together, but it won’t be in vain. Self-promotion alert … you might consider Pendo (my current product) which makes it easy to pull retroactive data without manual tagging and instrumentation.
• Iterate on the deck while the effort is in progress, but don’t rewrite history. What makes these presentations awesome is the narrative. It sets a great example for the team.
• Encourage the team to present as a group. It will be more impactful that way

Conclusion

Let me know how this works for you! In my experience, visual brainstorming works. Light peer pressure works. And face-to-face sharing inspires. Give it a try and feel free to ask any questions in the comments below.