Merging Product & Design at Lola

If you haven’t read it before, I previously discussed this topic in the PM-Designer tension.

For both of my previous jobs, “Product” was closely tied to Engineering. At Microsoft, we were part of the Engineering triad — PM, Dev, Test. At Kickstarter, Brett managed both the Engineers and the PMs. When I started at Lola, I was the only person working on Product (and I was the most “non-technical” person, so I slid over to fill those gaps).

Recently, we merged our Product and Design teams into one team. There are three of us, with overlapping skill sets. I cannot overstate how much this has helped us as a small team. By merging the groups together, we resolved most of the tension for who is responsible for what, and can better share the workload.

For example, up until our merge, I was responsible for roadmap creation across everything we were doing.

In the last couple weeks, we’ve been pushing very hard towards launch. My priority shifted towards working on our launch event, organizing usability tests, finding good friends & family users, triaging bugs, and answering last minute questions.

One of the designers came to me to ask about the roadmap after launch. “Ha,” I thought to myself, “no way do I have time for that right now.” I am not proud of this, but I shut down the conversation by giving a long list of reasons that the imminent launch was more important than the roadmap. (Everyone will tell you that a great PM can think about the day to day and long term. I wish I could do that. I can think about both, but sometimes one takes the front seat. For me it’s about timing and prioritizing, not about having both things in your head at the same time).

When I went home to think about it that evening, I realized the reason the designer asked was because he did have bandwidth to do the work, and was interested in doing it. Even though “roadmap” had been a PM task, he was perfectly willing and able to help out while I hunkered down on launch.

So the next day, I apologized and asked the designer to take a stab at the roadmap — giving him the previous one as a skeleton. He had time, and he made one. It wasn’t exactly what I would have done, but it gave us a much better starting place. Since he did that work, we could sit down together and have the conversation — saving me time, and him having a greater impact on the roadmap.

Meanwhile, the other designer was sat with our iOS engineers, learning how to commit his own changes for copy, and triaging the polish and copy bugs. Another task that could easily fall to be a PM or a Designer.

Of course, there are still tasks that are specialized. I’m more likely to coordinate between teams. The designers are more likely to do visual design (which I’m lousy at).

Before this experience, I would have said it was fine to be the first PM and work on a team alone. But, when the PM & Design teams are separate it’s tempting to split things by “who does what.” By putting PM & Design together, we’re able to learn from each other and help keep the workload consistent through the project. Also get the added bonus of making sure the company is design driven. Design is involved from the beginning, which helps us make sure the roadmap is focused on what we’ve learned from user research.

This won’t scale. Eventually the team will be large enough that we’ll have to split. If you’re hiring your first PM (and won’t have another for a while) consider putting them with design.