It turns out organising company-wide events has a lot more to do with product management than I ever imagined. Case in point: a regular company-wide product demo event that we recently redesigned. It was a great experiment with a short deadline and high stakes. On one hand, there was a big chance that I’d prove myself wrong. And if you’re inviting the entire company of more than 250 people to a meeting for an hour it better be worth it.
The demo and why it died in the first place
When we first started doing Scrum at Pipedrive the Demo was one of the rituals that came with it. We didn’t do it quite by the book though. Instead of the engineers making a demo to the product owner at the end of the sprint it was a company-wide event where new features were shown. With only one product team and a handful of non-engineers in the company at the time, it was a nice little event where people could show off their work and the rest could cheer them on.
By early 2017 the demo was dead. We had started doing it less and less often until it was decided to remove it from the calendar completely until we figured out what to do with it. There were several factors that contributed to the demise of the demo.
We had long outgrown the big meeting room that we initially used for the demos. The presenters kept using that room, but everyone else was observing via video call or from a separate all-hands area. Not to mention everyone that participated from our multiple offices in several different cities and time zones. This created a physical and mental separation between the audience and the presenters.
The demos tended to focus too much on the technical functionality of the features. We had decided to have the product managers do the demo at some point to counter this, but it didn’t have much effect. Once it’s your turn to demo and you’re sharing your screen with dozens of coworkers, it’s hard to resist the temptation to start clicking the buttons and explaining how the interface works. So we rarely got a good explanation of why this feature was built and how it benefits the salesperson.
It didn’t help that the demo was usually held on Friday afternoons and people started skipping it more and more as they were getting less and less value out of it. It ended in a negative feedback loop where the disengaged audience made the presenters less interested in investing in a great demo which made the audience even less engaged.
Product management toolset to the rescue?
We have great product managers at Pipedrive who generally don’t just accept the status quo. Some of them decided to investigate what had happened and how to fix it. They created a survey which dozens of people filled in. They also interviewed several people from different departments and presented their findings at one of our regular PM meetings. The results were grim: people didn’t feel the demo was needed at all. They preferred getting their information about new features from other channels, be it the company wiki, official blog posts, and videos, Slack or during personal training from product managers.
The solution seemed to be a combination of async communication channels (blog posts, short videos, etc). While I appreciated the effort they had put in, and objectively there was no question about the validity of the data, I could not accept this result.
I felt the assumptions held by the product managers when creating the survey and conducting the interviews were very different from mine. They seemed to believe the demo was about informing the company about the functionality of new features. I felt it was much more about feeling like a team, showing off the cool things we were building, celebrating the hard work that has gone into it and also explaining the reasoning behind the features.
Do opinions still matter?
Our methods of designing the product have evolved greatly over the years. Seven years ago the product-minded founders would simply design a feature and tell developers to build it. Today we have a team of more than 20 product managers, designers and researchers that dig into data, create surveys, interview customers and conduct user tests. There are methods like Jobs To Be Done, Outcome Driven Innovation, Lean Canvas, Design Sprint and a dozen other things that promise the right answers through an objective process. Just use the tools and the result is a perfect product.
While I strongly support using new methods and urge people to push the ways we design things at Pipedrive I’m also often worried about the side effects these things have. Sometimes it seems we have such a strong belief in a method that we truly expect it to do the innovation for us. That if we manage to map what a salesperson does every minute of every day and how frustrated they are during these activities it will lead to perfect product solutions for us.
Have we gotten hurt so much by strong-willed stakeholders who require us to build features on a whim that we’ve slipped too far in the other direction? Are we giving intuition a bad name because there’s no hard data behind it? Does truly deeply understanding your customer count for nothing these days?
I believe we need both. Opinions and intuition combined with the methods of validating and polishing the solutions. I believe it’s difficult to build a great product without the latter, but it’s impossible to create a great product without the former. So I kept questioning the results of the research and telling them there’s more to the demo than just spreading information.
Enough talk, just test it!
Our lead product manager pointed out to me that if the demo is about product vision, celebrating hard work and feeling like a team, it’s something the co-founder and Head of Product should be responsible for, instead of expecting the individual product managers to figure it out. He also might have promised to the entire company that I would organise the next demo within two weeks at the last all-hands meeting. Message received. I decided to test my assumptions and make a few changes in the format of the demo to see if we could get people engaged again.
We moved the demo to a Monday and invited everyone in the company. Due to some calendar conflicts, the only available option was a Monday the very next week, so we had less than a week to prepare. People are super busy as it is and it was quite a tall order to expect them to present with such short notice. I didn’t hear any complaints though. I also strongly believe constraints are critical in fostering creativity. It’s one of the reasons we have roadmaps and deadlines for features at Pipedrive, even though, in recent times, there’s a strong online movement against using these.
Because it was difficult for people to talk about the reasoning behind a feature while staring at the interface we introduced slides. So each team would first show a couple of slides before explaining the pain points in the lives of salespeople that lead to the solution. This presentation would be done by either the product manager or the designer, and then one of the developers would demo the functionality immediately afterwards. Both of them would also stand in front of the crowd in the all hands area instead of doing it from the safety of a separate meeting room.
We also decided to prepare more. This meant producing slides a few days in advance for most teams before I would make suggestions for improvements. The main goal was to channel the frustration of the salespeople when working without that particular feature, describing our process of arriving at the solution, and explain the future of the feature. Some features we’re currently building can seem very confusing at first glance. But if you can see them as simple strong foundations that are needed in order to build sales-specific features on top of them, they start to make much more sense.
We worked on a narrative for the developers doing the demo so it would support the claims in the presentation. So instead of simply clicking on each button and drop-down and explaining what it does, they would have a story to tell about a salesperson going about their work and how our new feature helps them accomplish it.
To help lure people to the event and make it slightly more festive we also provided refreshments. It didn’t hurt that it’s much harder to sneak open a laptop to multitask during the demo while you’re holding a chicken wing and a bottle of beer. So it helped with engagement as well.
What’s the verdict?
We had taken some risks with bringing back an event everyone felt was pointless. We had used up hours of valuable time of product managers, designers, and developers in preparing for it. And we had invited everyone away from their busy Mondays for an entire hour. Was it worth it?
The slides worked well. Some were funny, some more serious, but every team was able to explain why their feature matters and how it came to be. The designers and product managers were able to get their point across really nicely.
As we had seven teams participate and we only had an hour each team had less than 8 minutes to present. So each short presentation was quickly followed by a demo. The developers did a great job at telling the story from the salesperson’s perspective while showing off the functionality.
The audience was very much engaged. There were a lot of laughs and applauding after and during the presentations. Very few people were using this time for catching up on their email or Slack messages. I’m sure it’s not only because it was harder to do because of the refreshments.
At the end of the event, I conducted a very scientific survey to see if people felt the new format worked well and if we should have more demos like this. Most people raised their hands and made noise which meant they approved. There were also several spontaneous positive reactions both in person as well as in Slack about the demo.
By redefining the purpose of the event and making changes to the format we were able to get people engaged again. This doesn’t mean the research that was conducted was wrong in any way. It was just getting answers to the wrong question. And we can use these results to improve the communication of new features to the company. It looks like the demo is here to stay though. We will continue making tweaks and working out kinks. The biggest of these is making sure the demo works equally well for everyone in all of our offices across the world. And we’ll also do our best to keep in touch with our intuition while designing the product for our users.
Pipedrive’s office in Tallinn
Martin Henk
Co-Founder, Head of Product Management at Pipedrive
0 Comments