Shipping is a Feature: Some Guiding Principles for People That Build Things

In the back of my head I always have that product manager view of accountability and so rather than “advise” I much prefer to have a dialog in context and make sure accountability stays with the person asking. It is difficult enough to be a manager and avoid the constant pull of “telling people what to do” and certainly on big topics one really has to be careful. At the same time, spouting cliche’s like “what do you think” or “it depends” can frustrate folks. This in itself is a valuable PM lesson.

I’ve been really lucky (literally) to work with many amazing folks and so many routine interactions yield empowering and powerful insights that one can bring forward. I’ve used blogging over many years to share those and many are also republished in our book on strategy and collaboration.

In thinking about the question and some of the recent design-oriented discussions, here are five takeaways that have always guided me. They didn’t originate with me, except in the sense that I discovered their value while making some mistake.

For these five bits of advice, I chose to focus on what I think is the most challenging aspect of being a PM, which is achieving clarity and maintaining a point of view for a product when all forces work against this very thing. What customers value most in a product is that “it just work” or “does what it is supposed to do,” and yet at every step in a product, the dynamics of design work to make this the most difficult to achieve. For those that have not built products, understanding the context and dynamics of decision making while building something is a bit abstract.

Shipping is a feature. Every PM knows this but it is also the hardest thing to get right. As a PM you throw around things like “the enemy of the good is the perfect” or, well, “shipping is a feature” all the time, yet we all have a hard time getting a product out the door. There’s always more to do to get it right. The way this was taught to me was so old it involved software being shipped in a box on floppies, but the visual has stuck with me. When you ship a product in a box on the back of the box are screen shots and marquee features. What does not come on the box are lists of all the features you thought of doing or different executions you considered. It is that simple. Once you release the product you begin a new adventure building then next iteration. It is almost always the case that what you were thinking before you had customers will change in some ways in the version that comes next. So ship. Learn. Gather data. Iterate. Whether you spend three years or three months developing a product this motion is the same.

You get paid to decide.  Some people love making decisions on their own. Other people need socialization and iteration to make a choice. Either way can work (or not) as a product manager, but to be great you really do have to decide. Deciding anything important or meaningful at all means some people will disagree. Some might really disagree a huge amount. The bottom line is a decision has to be made. A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options. But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever. This is the really hard stuff about being a PM but the most critical thing, you bring a point of view to a product—if a product were a person you would want that person to have a clear, focused world-view.

Can’t agree to disagree. Anything that requires more than one person to do (and by definition as a PM you are working with Engineering/Dev so that means what you do) will reach a point where you have to do something and not everyone will agree. On a well-run team there are very rarely that many decisions that span many people all of whom have a voice (if you do, then fix that problem first). When you do reach a point where you just don’t agree, first, contemplate the first lesson and realize you have to ship. Second, see the next lesson and realize you do have to decide. That leaves you deciding something that some people (or one person) won’t like. What you don’t want to do is end that meeting over coffee with the infamous “we have to ship and I think we should do X, so let’s just move on and agree to disagree”. Endings like that are never good. The “told you so moment” is just out there waiting to appear. The potential for passive-aggressive org dynamics is all too real. Ultimately, this is just a yucky place to be. So if you’re on the “winning” side of such a dialog then you have to bring people along every day for a while. You can’t remind people who was right, or that it is your decision and so on. If you’re on the “losing” side you need to support the team. You can’t remind people when little things go wrong (which they will) that you were right. Once a choice is made, the next step is all about the greater good. Nothing is harder for technologists than this because as technologists we believe there is a “right” answer and folks that don’t agree are simply “wrong”. Context is everything and remember you have to ship–as a team.

Splitting the baby is, well, splitting the baby. Even with all those lessons, time and time again I’ve faced situations where there is a stalemate on the team and the suggestion is made for a middle-of-the-road choice. A feature will appear sometimes. Performance won’t be terrible, but it won’t be great. Customers can do 90% of something, but not everything. Yet it would be possible to decide to have the feature, have great performance, or deliver 100%—it is just that the team dynamic is placing a value on finding a middle road. The biblical narrative of splitting the baby often comes into play here, because in practice if you do arrive at such a comprise what you’ve in effect done is reached a state where in fact you have made no one happy in the room and no one happy down the road. Of course, compromise is a critical part of product design for many reasons. The bigger the team, the more varied customers, the increased divergence of customer needs all lead to a stronger need to find middle paths for complex choices. There is magic when you can do this without just muddling the product. But there is risk that if your design language turns into splitting the baby that the output is exactly what you don’t want to achieve.

10% better can be 100% different. The hardest choices a PM can make are not the new choices for a product—a clean slate is challenging, but that is the truly fun part of design for many. It is not easy, but it is fun. The real challenge comes when deciding what to do next time around (in three weeks, three months or more). The first thing you do is remember all those things you could not get done or had to decide sub-optimally. So you think you’ll go back and “polish” off the work. But remember, now you have customers and they are using the product. They might not see what wasn’t done. They might actually like what you ended up doing. Your temptation to tweak things to “finish” them might come across as better in an incremental sense, but will it be that much better for existing customers? Will it be so much better for new customers that it is worth the risk of touching that code again? The big question for you is whether you can really measure how much better something is—is it more efficient, faster, deeper, etc.? There are many cases, particularly in user-experience flow and design, where incremental improvement simply amounts to speed bumps in using a new release and the downside masks the upside. Sometimes when you improve something 10% what you really do is make it 100% different.

Context is everything in decision making as a PM. The skills and experience of the team matter. The realities of where the business is at a given time or the ability to execute on a proposal are all factors that weigh heavily. Hindsight is 20/20 or better in the world of PM, and we all know there are many standing by to offer perspective, advice, or even criticism of the choices a product makes.

If you don’t make those choices in a timely manner then there won’t be much to talk about. Sometimes the most difficult thing to do is keep moving forward. That’s why some of the most valuable advice I’ve received relates to the very challenges of making tough product calls.