Your Job is to Define the Product

Dear Product Managers:

Your job is not to sketch ideas.

I know. It is fun to work with customers and come up with really cool ideas. Much of the emphasis of your skills is ideation and how well you communication with users. I am sure you enjoy this and do it well.

But it’s not your job.

Your job is to define the product for our users so it can actually be built and deployed. If you want to get technical about it, your job is to provide detailed specifications that include both product improvements and the technical environments users live. But honestly you don’t always have a lot of control over that second bit. You do, however, have an enormous control over the first bit.

Of course, if you want to do your job well, it does mean that you may have to change some of your current behaviors.

For one thing, you need to make sure that the specifications you write (writing detailed specifications is still one of the main things you will do when doing your job, by they way) are actually possible on the users machines.

Did you know that web sites and applications have significantly changed over the last several years? I checked. Many things you want the product to do won’t run on Internet Explorer and a 4 year old laptops no matter how cool you want the product to be. (And many older configuration are not even secure enough that they should be allowed on the Internet!) While many things can be shifted to the server, the fact is that there is still such a thing as client side system requirements. So please make sure your specifications are limited to what the oldest computer and browser support. (And, yes, that does need to be part of your specifications.)

In fact, you’re going to need to make sure the product is useful to users in general as well as part of other business processes. I don’t really care if the code can run in production if it does not really meet customer needs nor if internal work groups are not ready to support it. Products run in the context of a customer base and support company, requiring business processes to unite them all. Without it, your product is a non-starter.

So, to avoid that, you need to check your changes across all company work groups required to support it. Every time. Remember, your job is not just to ship something. It’s to ship something that can actually be used to fulfill our customer’s needs. You can’t know it will do that unless you check that it works across the entire company.

Of course, before deploying the product, you’re going to need to make sure the product can be used by the customers and other users. I mean, you can’t simply have software development professionals test it and deploy it into production without user feedback. Set up a test group and test cases (provided to the development team to aid in their development efforts a well). Coordinate user testing with real users. Then run it and check it.

This is obviously harder to do if you’re in an environment where you are trying to continuous deploy new features and improvements, but the theory still you holds. When your specifications get handed over to development, you’re still responsible for it. Make sure that the specifications are really defining what you intended — and stay engaged to give feedback and coordinate acceptance testing efforts.

Another thing to remember is that sometimes users define things based on the most common cases, which means that it is not enough just to specify the main and happy path in perfect conditions. You need to make sure that the specifications include odd cases that need to support as well as what happens when things go wrong, like when required information is not available or duplicates can be created by a valid business case.

This is hard. It means you have to spend time thinking about the different things our users might do. But it’s an important part of your job, because it will result in specifications that actually define a working product, rather than a product that requires constant changes and updated because of edge cases and dead ends.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analysis so that we can see how well initial specifications match the final product and how much is left out that should have been identified. If you expect software development professionals to implement the product you specify, the you need to learn whether or not you have succeeded. How else will you know if your specification was well done? Because, as I’ve mentioned, if your specifications don’t reflect a product that can actually be support in production, you have not improved the product for our users.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

This isn’t true. You’ll be far more effective because you will actually be doing your job. If you get hassled for spending more time on a product or release, that’s a failure of management, and I apologize for it. We need to spend less time demanding that you move on to the next release and more time asking you to stay engaged from ideation to delivery. If you’re not doing that, I strongly suggest you ask management to allow it. If management still refuses, you should leave or be grateful for software development professionals that work countless hours making changes mid-stream to accommodate poorly-defined specifications and continual changes to requirements, which make your job ultimately successful. Which, not to beat a dead horse, is to make the product better for our users.

Please don’t feel like I’m picking on you. You’re not the only one who should be doing this job. It is all of our jobs to make the product better for our users. So please don’t take it was whining or complaining when software development professionals rise issues with schedule, features or user environment limitations. We are simply trying to define a product that can be delivered. It is our job to turn ideas into a running product, so work with us to understand how this can be done.

No matter what our job titles, our jobs are all the same — to deliver a product that actually meets user needs and can be run on actual computers. Every day. So let’s do that.

Thank your,

Your Software Developer