Lessons learned from building a product team
When we started building Pilot I had close to zero experience running a product team. We’ve built a lot of products for our customers, but our strengths were in managing the design and engineering part of the process. We had a lot to learn.
We started with a process closely modelled after Intercom’s. They had a team six times as large, but what they wrote about rang true. So we adopted it as is.
Five months later we had to scrap everything and start from scratch. Our product was nowhere near done. The team was consistently underperforming. Everyone was frustrated.
So what went wrong? For one, getting from nothing to a minimum viable product takes different skills and processes than developing an existing product. And two, until you understand the jobs to be done in your team, it’s unlikely that any process will work.
If you’re struggling with the same problem, here’s what worked for us.
We created a list of user stories for our process.
We wrote down things that need to happen, on regular basis, for the product to move forward.
Expressing them as user stories helps you understand what needs to be done and why. Here are a few examples:
- As a developer, I need someone to review my code so I can improve my programming skills and maintain or improve the overall quality of our code base.
- As a designer, I need to clearly understand what a particular feature of the product should do, so I don’t have to re-design it over and over again.
- As a product manager, I want to know how much the team can done this week so I can correctly communicate our progress to the rest of the company.
- As an engineer, I want to be able to frequently deploy to production without having to worry about breaking something.
- As a product manager, I want to capture ideas and product feedback so I can incorporate them into our roadmap.
We ended up with a list of 20 or so processes like the ones above (although written in a slightly different format).
We started with something simple.
Instead of adopting a complicated workflow or methodology, we started with a minimum viable process based on the initial set of user stories.
This wasn’t a collaborative effort. I sat down and put together a set of tools and processes (mostly meetings) that I thought would work, explained to the team how we’re going to work, and we were off to the races.
Getting started right away, even if our process wasn’t perfect, was what made this whole thing work. Design-by-committee would’ve let to days or weeks discussing what an ideal process would look like. We got two weeks of solid product work done instead.
This initial momentum was important. I helped us stick to our process. Most habits (including things like diet) get abandoned because people don’t see results early enough.
We built in feedback loops and iterative improvement into the system.
The process we started with wasn’t perfect, but it had two things going for it:
- We knew exactly how we’re doing because we measured our velocity on weekly basis.
- We had a mechanism for capturing feedback and issues with the process, and a way to resolve them.
We keep a project in Asana called Product Retrospective where everyone can report feedback or ideas about how our team is run. We go through the list every two weeks, everyone nominates issues they’d like us to focus on, we discuss possible solutions and assign tasks to put them in place.
So even though our initial process wasn’t perfect, it was getting better every week. And we didn’t waste time fighting over process because everyone knew that if they want to change it all they need to do is wait until our next retrospective and bring it up.
These two mechanisms, coupled with a very simple process that we monitored on daily basis, helped us get from something we felt was unshippable to a live product in 3 months. After another three months, our product was further away than we thought it would be in a year.
We are still working on it.
Our process still isn’t perfect. It never will be. But over the past 5 months we ran 10 retrospectives, each making the way we work a little better. And because these improvements compound over time, we’re getting more and more done with less effort.
Hopefully this helps you avoid the mistakes we’ve made. Building a product team is hard. We are learning every week and we are by no means perfect. But we’ve created a culture of continuous improvement that applies not only to our product but also our team.
If you’d like to share your story, please email me at matt@pilot.co.
