Scaling Agile at Pipedrive (and the use of fireballs in creating product vision)
•
1 like•225 views
Keynote by Martin Henk, CEO at Pipedrive from #SaaStock17, Scale Stage, RDS, Dublin, Ireland. 20th September 2017
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
More from SaaStock
More from SaaStock (20)
Recently uploaded
Recently uploaded (20)
Scaling Agile at Pipedrive (and the use of fireballs in creating product vision)
- 1. And the Use of Fireballs in Creating Product Vision @henkmrtn @pipedrive Scaling Agile at Pipedrive
- 18. + = Me 1.0 Product Me 2.0
Editor's Notes
- We’ve learned a few things over the years going from “what’s a product manager?” to having 13 Scrum teams ship product in parallel
- Some learnings are very personal. Such as when I learned to be less of an asshole when I moved back to Tallinn and took over the product department. I will never forget the face of one of the designers when he had to witness me and a fellow product manager screaming at each other all red faced about a seemingly trivial matter. I got super lucky as the team didn’t hold back calling me out when I was acting stupid. This enabled me to take notice and improve.
- Some lessons are organizational such as how to get a bunch of developers to start doing Scrum properly. Turns out you need to hire a guy named Sergei who looks like Jason Statham and doesn’t accept any bullshit to come in and fill everyone’s calendars with Scrum ceremonies.
- Funny sounding events like grooming and retro. We thought we were doing Agile before he came. And to our credit we were shipping early and often. Apart from that it wasn’t agile, it was just messy.
- Some lessons are, again, very personal and about not being a bottleneck, giving up control and understanding you might not always have the best solution to every product problem. I used to do support for about 3 years and after thousands of customer interactions I had a pretty good understanding of their problems. It took me quite a while to realize this doesn’t always translate into knowing how to best solve these issues.
- A lot of it came to me slowly over the years. One of the moments of clarity was last summer while we were doing our first Design sprint. For the ones not familiar with the concept, it’s a method of validating any product idea in five days the fine people at Google Ventures have formalized into a book and a guideline.
- We used it to get on the same page with a particularly tricky project where the problem was clearly understood in the company, but we couldn’t agree on the solution. A key concept in Design sprint is voting on potential solutions anonymously and without being able to advocate for your idea vocally. The wireframes are hung on walls without attribution and everyone leaves their votes in silence. The concepts with the most votes win. My solutions didn’t get any votes at all. Which was a painful, but very necessary lesson to learn. You’ve hired professional people into these designer and product manager roles. Of course they’re better than you. Just get out of the way, will you?
- Some lessons have been very mundane and have to do with distance and time zones. We thought we’d be able to run product from Silicon Valley with the entire product team being in Tallinn if we got everyone doing Scrum properly and hired some product managers. The 10 hour time difference proved stronger than us. We kept building product of course, but the amount of time wasted on the back and forth at ungodly hours and shifting priorities by the time something was formalized was just ridiculous.
- Most of the issues we’ve encountered over the years have had solutions. They have required various degrees of pain and time to come up with one, but usually you solve it and move on. But there’s this one issue that has been bugging me for years that we’ve tried to address multiple times with mixed results. I’ve felt we nailed it a few times, but it always ends up coming back. It’s the issue of getting the product vision out of the brains of the founders. It’s a tricky subject as one of the product minded founders has had brain surgery a few times over the past 7 years, but I promise you it wasn’t related to getting to the product vision.
- So what exactly is the problem again? We have 13 product teams shipping product at the moment and we keep hiring. No single person can realistically have an informed opinion over every single decision these teams make every day. As time goes on, each of the teams going deeper down their own rabbit hole. Some team becomes experts at sales reporting, another team at time management. The mobile teams know more about mobile than I ever will and so does the email team about email. You get the point.
- We’ve learned to do more and more research over the years, the researchers, designers and product managers talk to customers more than ever before. Each of the product managers has a deep understanding of the problems customers are facing in their area of sales related actions. The designers spend a bigger and bigger portion of their time talking to customers, drawing diagrams and building somewhat crazy-looking contraptions on the office walls with red thread. So it only makes sense to get out of their way and let them decide what’s next and what’s best.
- But how do you ensure they’re all building Pipedrive? I mean really, when I first started reading about independent product teams operating at larger companies a few years ago I thought these people were out of their minds. Or simply didn’t have product minded founders that could lead these teams properly. Because surely this could only end up in a complete disaster of loosely coupled independent features that no one in their right mind would want to use.
- It looks like the solution for us was using Fireballs. Yes, you heard that right. We’re using Fireballs to communicate the unified product vision to the company so that each team can still operate increasingly independently while maintaining a cohesive product.
- Ok, this deserves a slightly better explanation. A while back marketing came to us with a problem. They felt we needed a framework that both the marketing and product organizations could use to describe and develop the product. To get us on the same page so to say. Or to sniff the same glue to use their own words. We were intrigued by this proposition. We decided to use the Jobs to be Done framework for it.
- It turns out there are multiple Jobs to be Dones out there. We chose the one Alan Klement and Eric White are representing and ended up doing a couple of workshops with them. Most of us loved the concept and the workshops, but the name “jobs” kept holding us back. First of all everyone immediately develops an understanding in their heads of what this means the moment they hear the word “job” regardless if they’ve read any of the books. It’s even worse if they’ve read something about any of the other job to be dones that are out there. It can very easily degrade into an endless loop of discussing semantics without ever getting anywhere.
- In the end we decided to keep the essence of what Alan and Eric had told us along with one of the pictures they used to illustrate the idea. It’s a picture showing a middle aged plumber who’s trying to kill turtles by jumping on them. The plumber then touches a flower which gives him the ability to throw fireballs. Which in turn makes killing turtles so much easier.
- For the ones that didn’t grow up spending way too much time playing on their Nintendo it’s a reference to a somewhat well known video game.
- How we ended up seeing jobs to be done was through the end user making progress and becoming the perfect salesperson. We imagined all the possible traits such a person would have and described each in detail. We decided to call these Powers and the entire process Fireballs. Fireballs because of Mario. And because it sounds fun.
- We considered other options such as skills to be had or habits to be acquired. Power fit best as it’s something that can be taken away. Like a human riding a bike acquires the power to move much more quickly and when the bike breaks they go right back to being slow. The same with software. A salesperson using Pipedrive might become the most organized and punctual person alive, doesn’t mean they can remain this way when not using Pipedrive.
- So what’s the benefit of using Fireballs over all the other ways of communicating product vision? And isn’t that just a fancy word for personas? We’ve tried to describe our product vision in many ways over the years. We’ve learned that it’s possible to create a memorable and engaging product vision. That is too general and vague to be useful when making everyday decisions. And that it’s possible to create a very detailed description that could potentially be useful. That is so long and boring that no one can be bothered to read it and it never gets used.
- Describing the perfect end result through the perfect sales person has the benefit of being quite specific while not dictating any solutions. For example we say the perfect salesperson always has the next step scheduled and never forgets about an agreement with a contact. This is memorable and specific without mentioning how this result is achieved.
- This approach is similar to a persona as it’s also describing an imaginary person that is representing the end user. But in fireballs we’re not interested in any traits that classify the person such as gender, age, job title, geographic location or anything else like this. We’re only describing the powers they have as perfect salespeople. Some people might be able to be this way without Pipedrive, most people need help in at least some areas.
- We’ve created illustrations about all of the powers using as many human figures as possible. We’re now in the process of spreading the booklets all over our offices. We will follow this up with posters and comic strips and anything else that makes consuming this material as pleasant as possible. We feel this will help us scale our agile organization so that the teams become more and more independent while keeping true to the product vision and keeping it all together in a product that our users love and that makes them more efficient.