In recognizing that our periodic meetings to share our development progress were falling flat, I decided to revamp the company-wide Product Preview event.
For many years, our company had maintained a recurring "preview" meeting where all employees were invited to catch a glimpse of the most recent product developments. At each meeting, a rotating group of Engineers would take turns showing off their team's work, which frequently included partially finished features that often led to unproductive Q&A with the assembled audience.
I believe the original motivation for having these meetings was well intentioned. It can be difficult for other parts of the organization to appreciate the black box that is Engineering. By revealing to the larger group the fruits of all that labor in a product demonstration setting, all interested and affected parties have a better opportunity to stay in sync.
But in our organization, these regular updates from the tech side of the house were not working. It was difficult for non-Engineers to relate to the material. We needed more structure, more context, and a bit more sizzle than you might expect from those who spend the majority of their time with variables, algorithms, and debuggers.
What drove this decision
Engineers seem to communicate best when they're speaking with other engineers. I don't think I'm inviting controversy by stating that Engineers are not the best orators. Public speaking is not necessarily a skill that helps them with career advancement, and perhaps part of what makes this particular field more attractive to them. Either way, a company-wide meeting with an exclusive Engineering agenda is going to have its challenges.
Engineers also tend to have a myopic view of their work. Even when you find a vibrant communicator, they will still struggle to connect their important contributions to the larger picture. To be sure, getting that new feature to work is a great accomplishment (especially when you factor in the additional challenges of having to upgrade to the latest, post-beta, open sourced, cross-platform, fault tolerant, minimal footprint, backward-compatible, mobile-optimized, ...)
But in a larger group setting like this that draws a cross-functional audience, there is an even greater need to tie the product-level work back to the higher-level company goals. I needed to find a way to continue to report on the great progress we were making but in a way that better catered to the entire company.
The decision: Substitute the Engineering-led, tech-heavy, feature-level demos with a Product-led, value-driven, full on show-and-tell lineup
To clarify, I still want the Engineers to join in. And the meetings would still center on product demonstrations - that is still the best way to share with the company the progress we're making on our products. What I wanted was to tell that broader story, where product innovation is ultimately tied to business value (ours and our customers'). More than anything, I was intent on having the entire organization understand our motivation, what drove our priorities and how we were validating our hypotheses.
Our organization happens to be following an Agile software methodology, but I want to be clear that the show-and-tell meeting I'm describing here should not be confused with the Scrum Sprint Review. There is great value in having Product and Engineering conduct a meeting to share progress, review what was and was not accomplished in the most recent sprint, troubleshoot issues, and critique each team's work (see here for more information on Scrum's sprint preview). In fact, it would not be uncommon to also invite the same audience to the Sprint Reviews.
Plan of attack
After a quick poll of the other department heads, I confirmed the approach and verified that I would not be disrupting any dependencies they had that would have stemmed from the original meeting. And, as soon as I felt confident that the Product team was prepared and ready to take the lead, I cancelled the old recurring meeting, then created a new meeting invitation with a revamped agenda based on these goals.
Review Customer Success from Past Releases
I am intimately familiar with large product efforts that were, at one time, deemed high-priority or "must-haves". But I've also observed that, too often the very next big feature quickly distracts us so that we lose track of what happened with the last one.
I wanted to start each meeting with a brief update about the last release, and specifically what we could report from our customer base. We had been improving the tools we use to help us better measure customer uptake. The Product team would continue to refine these reports to help communicate the return on our past product investments.
Did we hit the mark on the last release?
- Who was using the new features?
- Who wasn't?
- Were the bug fixes received well?
- Is the product more stable, less glitchy, and scaling well?
- What else did we learn?
DEMO NEW PRODUCT DEVELOPMENTS AHEAD OF the UPCOMING RELEASE
For most attendees, the draw of these meetings was still the shiny new features and we certainly wanted to use the opportunity to spotlight all the great work accomplished since the last release/meeting. But the switch to having the Product team members present the updates meant that they were more likely to hear how individual enhancements fit into the larger end user stories, how the updates might affect the configuration and pricing of the products - even how we might alter our product positioning in the market.
We also want to illustrate how the latest changes were building on previous rounds of investment rather than just demoing individual features in apparent isolation.
The Product team is always collecting feedback to validate our efforts but this would not have been the first time the other departments would have seen these product updates. At these Product Release Preview meetings, our intent is to show off features that are complete and already scheduled in the very next product release.
REVIEW THE CURRENT PRODUCT ROADMAP
The Product team has been putting more energy into the roadmap planning process itself and worrying less about adhering to any particular iteration of the roadmap. These meetings proved to be an ideal opportunity to update the company on any significant changes we had made to the roadmap since the last gathering. I intentionally scheduled this topic toward the end of the meeting to time box help keep the interactive conversation focused and productive.
At this time, the Product team has not committed to publishing a refreshed Product Roadmap at each meeting.
RECRUIT CUSTOMERS FOR PRODUCT RESEARCH
We close each meeting with our continued plea to get everyone's help in recruiting customers (and prospects) for our ongoing product research initiatives. We have found that our calls for help tend to yield more fruit in the larger group setting, especially after delivering a rousing product demonstration.
Part of the motivation for these changes was to stir up some excitement around all the great product work that goes on behind the scenes. Celebrating your accomplishments and sharing them with the entire organization is healthy for any team and can really boost company morale. And we certainly achieved that with the new format.
With the changes I made to the agenda for this "preview" meeting, I also helped distinguish these Product show-and-tells from the Engineering (Scrum) sprint reviews. And based on the informal feedback I received, our Engineers were actually relieved that they would not have to present to the group and that they would be excused from even attending the meetings - although many of them still show up and participate!
I consider this particular decision a great success and will share more about the impacts in future posts.