My previous article on the dangerous rise of “crazy-busy” product managers generated quite a bit of feedback. One part of the article that was a bit of a throwaway, but became a focus of many of the questions I received, is on the way we have our team leads work on product specs. As a recap, here’s what I said:

The point is to think about areas where you do all the work or where you’re a bottleneck and you don’t need to be. In our case at Postmark, I frequently got overwhelmed with spec writing. So we changed that. The lead designer/developer on a project now writes the first draft of the spec (we have a really nice template), and the rest of the team (including me) comes in afterward to ask questions and polish to the doc. The added benefit? Those team leads now have a way better understanding of the work they’re about to do, and they also feel a strong sense of ownership.

I got questions about the template we use, as well as how team leads find the time to do that. So I wanted to give a little more context on that.

What template do you use?

There is no shortage of “product spec” templates out there, so the one we use isn’t particularly groundbreaking or new, but I like it for a couple of reasons.

First, we’re very serious about the “living document” nature of our template. We don’t fill out the whole thing up front, we host it in Dropbox Paper, and everyone on the team has full edit access. We truly work on it together.

Second, I’ve had over 10 years to iterate on this. So yes, there are many product spec templates like it, but this one is mine. I like the focus on defining the problem, the market, the risks, and the success metrics before anything else happens. I like the modular nature of it — just use what’s applicable to the project. And I like that it’s fairly short and focuses only on what’s needed.

You can view the template on Github. Feel free to send me feedback!

Where do your team leads find the time?

I guess saying that our designer/developer leads write the first draft of the spec raised some eyebrows. So let me address that. At Postmark we’re constantly evolving our development process. As of now, we usually plan for 10-week development cycles (which includes multiple smaller releases). This is followed by a 2-week “off-cycle”.

During the off-cycle we don’t take on any new projects. The team uses this time to polish anything they didn’t get to during the regular cycle, focus on some bugs they wanted to get to for a while, respond to customer feedback, etc. But we also use this time for planning. This is when we get together as a team to discuss the problems we want to solve in the next cycle, and work on planning together.

So the answer to the question “Where do your team leads find the time to write specs?” is simply: we give them time. Their “project” during the off-cycle is planning for the next cycle. Thinking through the problem, consulting colleagues, learning any new skills that would be helpful — this is all you are focused on during those two weeks.

This has worked really well for us, because we start every new development cycle with a good understanding of what we want to accomplish. Our teams are fully immersed in the process, and have full ownership of their solutions. And I feel much better too, because I was able to spend quality time on each plan, asking questions, guiding where needed, and making sure we keep our focus on the right things.

Of course this solution won’t work for everyone, so this isn’t really advice. Let’s call it “shared experience.” I’m not saying everyone should work this way. But I will say that it has made us much more productive and efficient.