Hi, I'm Ryan Singer. I design products and manage teams at Basecamp.

« See my home page for more articles about interface design and product management.

Get the RSS feed to find out when I post new articles.

Follow me on Twitter for a steady stream of thoughts and relevant links.

Mar 20, 2012

Advice for product managers

I received an email the other day from a fellow asking for help defining a product management “philosophy” or “process” at his company. I wasn’t sure I would be able to help, but once I started typing a lot of information came out.

I’m reposting my response here in case it’s useful to other software product managers who are trying to define their role and improve their process.

What is product management?

“Managing the product” means deciding what we do to the product and then making it happen.

When you unpack that, it involves strategy (what is important to do?), resources (how much time can we spend on it?), managing development (what do we need to build in order to do it?), managing experience (how will it look and work, how does it integrate into what we already have?). And all of it with regard to the bottom line of the business. Given a strategy, resources we have, a user experience bar to uphold — given all that, what can we do and why is it worth doing?

Defining units of work

In order to manage this, we have to be able to break our ideas and efforts down into manageable projects. I try to find ways to define any effort in a < 2 week chunk. If there’s truly a lot to do, like a complicated new feature or a big change, I’ll try to break up the work into orthogonal or serial pieces that can be done in separate < 2 week chunks.

A core skill with defining units of work is being able to understand dependency in the design and code. What can we change without affecting other things? What can we change that creates the improvement we want while staying isolated within known boundaries?

In other words, you don’t want to start working on something and realize it opens cans of worms and affects everything else. You have to be able to draw a line around what you are doing and say “we will change this but not that.” For this, it is very helpful if you can think like a programmer. This is a good programmer’s expertise — the interdependence and interfaces between parts. If you aren’t a programmer, have a programmer with you when you try to define chunks of work so you can be secure about the boundaries on the code side.

Deciding what to do

I try to lead every decision with user experience. What is the user-facing situation we want to change? Or if the motivation isn’t because of a user benefit, but a pure business reason — what is the impact on the user, and how can we align incentives so this at minimum makes sense to the user? This is critical.

The other thing is … often in software the thing we think we want to do isn’t actually the right thing. We have to imagine what we want, or stakeholders imagine what they want, and then it all sounds good — until you actually build it and try it. So it is critical to be skeptical of your own ideas and lead with design. Mock ups, stub prototypes, etc, that give you some first-hand experience of what it’s like to use the new thing.

Design & development process

How can design lead the process? On my teams designers go as far as they can to build real working templates against a mock back-end and then the programmers connect the dots behind the scenes. This way we have the maximum confidence about what we are building before investing programmer time.

Once the process is started, and programmers are implementing, we don’t bite off too much at once. We want to design one thing, implement it, and then see it in action. The design -> program -> review cycle is critical and it works best when it is a small and tight cycle.

Throughout the design -> program -> review cycle, it’s important to focus on flows not individual screens. No interface or piece of software is in a vacuum. People got to it from somewhere else, trying to do something. And after they do it, they go somewhere else. The more you can think of terms of sequences of action instead of static elements, the better. A flow is a better review target than an element or screen.

On my projects, programmers and designers work on the same code-base. Both have the app running locally on their machines. This is critical in my view.

One more point on development process. While design leads, they aren’t immune to feedback from development. If the programmers say something is hard or annoying, that should be a factor weighing in the design decision. It’s not a hierarchy with design purely on top. Rather it’s a path-dependent process, where the two alternate feedback, but it starts with design and the final evaluation is on the side of customer experience.

Communication and management

I like to create a Basecamp project for each iteration. I cluster the tasks around reviewable targets. By “reviewable target” I mean, if we checked off all these things on the list, it would bring us to a point where we can evaluate the result.

For example, if you had a list of “programming” todos and a list of “design” todos, you never know when you are at a point for review. But if on the other hand you had one todo list for “signup form”, and it needed both design and implementation, when the items are all checked you can load the signup form and evaluate whether the work was done well or not, and where to go next.

I’ve had good success with a daily status message, where each person posts at the end of the day anything important that they accomplished. It is async, so you don’t waste time on a status meeting. And it gives a sense of accomplishment/celebration at the end of the day.


One of the best words you can internalize is “satisfice“ — in other words, “done enough” given a certain goal. There is no absolute measure of “done.” It’s up to you to decide, because all projects can go on forever. The best way to determine when you are done is to again lead with design, where the function of design is to reach a solution to a problem. When the problem is no longer a big enough problem to matter, you are done.

Like when you have a headache. If you don’t take enough painkiller, it doesn’t get better. But if you take too much, not only is the headache gone, but you’ve gone past that and you’re floating up in the clouds. It’s easy to keep improving on something past the point of customer value.

I hope this overview touches on the many sides of product management and gives you a sense of the major themes that lead to good results.

What do you think?