The Executor — Part I

A product manager is a unique position in the sense that it can be very different from one organization to another. Moreover it can be different from one product manager to another in the same company. Having said that, we can find core responsibilities and goals that will be relevant to most product managers, most of the time.

Most product managers have 3 stages in their product development life cycle. Discovery — where we plan our product and what we want to get done. Execution — where we actually build our product and get things done; And post launch — where we measure our success and respond to our users.

A lot is being written about product discovery, planning and post-launch. The never ending quest after the holy grail of product, product-market-fit, has brought a lot of advice and input on how to get the right features and how to measure success. It seems like, somewhere along the way we forgot how important execution is (You can have an idea for a killer product, it won’t mean much if you can’t actually get it to users).

I, therefore, thought it might be a good idea to discuss execution for a bit and explain why, in my humble opinion, you will never be a great product manager if you don’t master it. I hope, by the end of this you will understand the importance and benefits in being a key part in your product’s execution.

Before we dive in, two small issues. First, I will use the word “Product” to describe development but everything holds true to features development as well. Second, I will talk about timelines. In order to keep things simple I’m referring to a single timeline. This, of course, is not usually the case when you deal with multiple products and each one is on a different stage.

Let’s define execution

First of all, let’s make sure we are all talking about the same thing. Before the product is launched, we have two stages of product development. The first phase is the ‘what to build’ stage and the second stage is the ‘how to build’. The ‘how to build’ is the part of these two that is being referred to as ‘execution’. It is that period of time, between the point when we have a defined product to the point we launch it.

The ‘what’ has things like Product strategy, Market research, ideation and users research — all of these, and other activities included in that stage, are aimed to answer one single question ‘what to build’.

The ‘how to build’ is not so straight forward. It will not only include the engineering work needed to implement the product requirements (‘building the product’), it will also include other activities such as marketing, customer service, onboarding, field enablement, analytics and more. These activities do not deal with ‘building the product’ but they are, definitely, things that need to be done in order to support the delivery of our product to end users. Therefore, I suggest that the correct definition for this stage won’t be ‘how to build’ but ‘how to deliver’.

As to the scope of activities included in this stage; We cannot use a closed list of actions when we define execution. Product teams and processes can be very different. The things that need to be done for a delivery may vary significantly, not only from team to team but even from one feature to another.

To sum up, we’re saying that execution is any activity we need to perform to get our product delivered, after we have decided on the ‘what’. So, I would suggest this definition:

execution (n):

The carrying out of actions needed to promote the delivery of an already defined product or feature to the end user.

Who should do that?

Now that we have a ‘dictionary’ definition for execution. Let’s take it to the next step. The definition that we have says nothing about who is the person (or persons) responsible for actually getting things done. If R&D develops, Sales, Customer Service and Marketing do their thing and every other angle is covered — we have execution. Why is it the product manager’s business? Can’t we just hand over our requirements and get a working piece of software on the other end?

No, we can’t. More than that, we also really shouldn’t want it to be like that. Keep in mind, as product managers we need to ensure that our product is a success. With that in mind consider the following (The list is really not exhaustive):

1. Missing delivery dates is first of all the product manager’s problem — This doesn’t mean that we’re accountable or that we’re to blame. But if something happened that prevented us from delivering our product to our end users on time — it’s our problem. We are definitely part of the process and should help to make sure that everything is done to prevent that.
2. We want to be there when our plan meets the reality — To paraphrase, “The PM makes plans… and reality laughs”. Suddenly our five-points estimation gets to be more like thirteen. Sales are having a hard time with our materials and the colors we’ve chosen for our design don’t match. We have to be part of the process so when these happen, we can respond swiftly and provide solutions. No one else can make good tactical decisions while keeping in mind our strategic goals and initiatives.
3. We are best positioned to be the orchestrator — engineers, designers and business are all part of the process; at some point it’s a big band. This is our day to day job and execution is not different — we are the best people to make sure the band keeps on playing in tune.
4. We can make changes in requirements if needed — sometimes it does happen. You wanted to create an orange button, but it’ll take 10 days; a blue one will take 2 days. You wanted to write “I’m loving it” in your microcopy but legal said it might be an issue. Reality is that we sometimes have to compromise and it’s part of our job to ensure we deliver the desired value in a reasonable timeframe. Not being part of the process will make this much harder.
5. Quick wins — no one can connect the dots as well as the product manager can. Sometimes, while implementing a feature you see an opportunity for a quick win. You don’t have to do it as part of this implementation (and more often than not, you should avoid it) but you can put a pin in that point and go back to it later. Only someone with deep business, market and product knowledge can effectively connect the dots like that. And that’s the product manager.
6. It will make you know your product better — knowing the ins and outs of your product is extremely important. You don’t need to review the code for the developers but understanding the architecture, and why engineering have decided to implement that specific solution can, at times, be priceless.
7. And the best reason — it allows us to keep our documentation lean — “Communication over comprehensive documentation” is the favorite agile value for a lot of product managers. And for a good reason. But we can’t just ‘not document’, We have to ‘communicate’. And I believe that once you’ve gone with communication, you have to communicate for all parts of product development life cycle.

The only open issue is to what extent are we, as product managers, involved. Well, that depends. There’s no ‘one size fits all’ for this one. It is different when you’re a single PM working with one development team and don’t have to deal with anything else; or when you’re a PM working with a project manager, a delivery manager, three dev teams and multiple business departments. But, as a general statement, execution, at least at some level, is part of your job. Not only that, a part of your job that you should really want to do..

What’s next…

So, it’s part of our job But this surely can’t be it! What are we not responsible for? How can we prepare ourselves better for execution, is there a Guillotine somewhere and how does Spiderman fits in all of this…?

All in Part II.