.

Everything is a product management problem

Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

I was going through some posts I had written years ago for other blogs when I happened upon one that—while originally targeted at helping folks reassess their careers—seemed to play really well in the realm of being an entrepreneur and building startups.

The basis of the post is this: Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

The same techniques and skills you use to manage product development can be applied to your startup, your business plans—and you, yourself.

It’s about compromises and resources and time. It’s about ship dates. It’s about controlling feature creep. It’s about making go/no go decisions. It doesn’t matter whether you’re an engineer, marketing, management, or sales. In the startup world, everything is a product management problem.

With that in mind…

Everything is a product management problem

Now, I’m no expert in product management. But let’s be honest, if we sat around and waited for me to write only on things at which I am expert, we’d all be in for a long, cold wait. So, all of that aside, I do know a number of good product managers. I’m even luckier to know a couple of exemplary product managers.

And because of that, I’ve gleaned—at a very high level—some insight on product management. I mean, I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?

  • Meeting : Me: “When are we scheduled to launch? What’s the date?”
  • Meeting #2-#999999: Me: “Does that affect the launch date? Is the launch date slipping?”

Yes, vital component. That’s me.

But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.

And here’s where the worm begins to turn.

So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.

How so? Well, let me outline some of the high points of product management.

  • Timeline / Road map / Lifecycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life. And every change that is made is reflected here. All the new features, all the slips, all the last minute requests, all the executive force ins. Not only is interesting and vital to managing the process, it’s one hell of a document for the post mortem. And it’s the polar opposite of our next item.
  • Trade offs and compromises. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
  • Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy more time? Can I buy more resources? Do we have to build? Can we partner? Can we acquire?
  • Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.

So taking those high-level points, shouldn’t we all be product managers for everything we’re doing? Shouldn’t we be product managing our startups? Product managing our investors? Product managing our employees? Product managing our product?

I mean, couldn’t your startup use some product management? A timeline? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your startup include? Is it Windows, Mac OS, and Linux compatible? What mobile platforms do you support? Where are your feature/function gaps that could move your startup forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?

How’s your startup’s usability?

Think about it. Your startup will be better for it.

(Note: I tweaked this a little. The original post ran under the title “Product management is everything and everything is product management.”)

(Image courtesy Jeff Kubina. Used under Creative Commons.)

  1. Good post, and it’s giving me a lot of food for thought on how to apply PM principles to all aspects of life/business.

    I do disagree with one part though, and that is the focus on timelines. I think timelines can lead to overplanning which leads to too much talking and not enough doing. Instead, I think prioritization is more important than timelines. Know the order of things you need to work on things to get them done, and then go do them.

    High-level dates are fine, but an over-emphasis on delivery dates result in unneeded stress and too much time explaining the reason for slipping on the timeline. After all, humans are terrible at estimates…

    I just wrote a post about this yesterday, but I don’t want this to seem like a linkbait comment, so I won’t post the URL. I’m sure you can find it if it is of interest 🙂

  2. Good post, Rick. I’ve been using a lot of my PM experience over the past few years on managing the direction & priorities of our company, and you’re right — once you realize that you can take your prior tech/project/product skills & apply them to non-IT initiatives, the road ahead becomes a little more familiar for techie-turned-entrepreneurs. Not that things are necessarily easier, but you can at least apply some known techniques & methodologies to targeting goals, producing a plan, and executing your way ahead.

Comments are closed.