I recently had a conversation with someone who co-managed a healthy sized organization at Microsoft (~50 program mangers and engineers). The goal of the chat was to explore some customer development techniques her team had been using to try and learn how they could be applied to the work my team was doing. But right off the bat, the conversation took a turn I hadn’t expected. Some of the work she had been doing was pulled in the 11th hour and she seemed disenfranchised with her lack of control and autonomy over the product. Her argument was, that even as a PM Lead, you are basically only the owner of a feature and not of a product. Therefore, you don’t have enough span of control to effectively employ customer development. This disempowered line of reasoning runs completely counter to my personal philosophy. As such, I have spent the last couple of weeks mulling over the conversation and pondering the relationship between span of control, influence, customer advocacy, and sense of responsibility.
My Philosophy of Program Management
Back when I was a junior developer, I enjoyed tinkering with and building new things. Coding was the ultimate playground. Simply think it up, imagine how it works. and suddenly it does. As a person who enjoys problem solving, the job of a junior developer was great. Someone would bring me a puzzle (a spec for a feature) and I would go solve it. Success was fairly black and white, the code either worked as the spec said or it didn’t. But when I switched to being a program manager, the problems shifted. I was shoved into a world of grey. I have a buddy who summarized the difference nicely. When his developers were teasing him about the length of time to write his spec vs the amount of time it took them to write theirs, he replied:
“You were handed a spec that says what needs to be built. Then you wrote a spec that said how to build it. But, who writes the spec for me?”.
With my background as a developer, I found it easy to write the spec that describe the technology that needed to be built. But, as a new program manager, the hard part for me was figuring out what needed to be done in the first place. My manager at the time beat a few principles into me that helped me navigate the waters.
Be the expert on what’s best for the customer – it’s the ultimate trump card.
As engineers, our first instinct to help a struggling customer is to add a new feature to make it easier. We naturally want to solve it with more code. Sometimes adding yet another feature is the worst thing you can do. The challenges that your customers face can have many causes, but only some warrant more code and new features. For example, a customer may be overwhelmed by the complexity of the UI. Another may be trying to do something with the product that it was never intended to do. Figuring out the right next move can only be done by stepping back and taking the time to have a crystal clear picture of exactly who the target customer is, what they are trying to accomplish, how they do their work, and where the pitfalls and challenges lie in their path. With that deep knowledge it becomes clear how to shape your product to help them achieve their outcomes.
IMPOSSIBLE == I AM POSSIBLE
It’s an extremely cheesy statement, but it does hit the mark. Once a program manager deeply understands what their customer needs and know what needs to happen, they are ready for the fight to bring it to life. A great program manager has a thick skin, an entrepreneurial spirit, and even a bit of stubbornness. For others will build the product but they will it into existence. Many roadblocks always get thrown in the way. A great program managers tears them down and makes stuff happen anyway. Only that drive keeps a project alive long enough to become a product.
Feel responsible for more than you own.
The number of things that you truly own and have control over is extremely small. Unless you are the most junior of program managers, the real job is to work across teams and convince people to do the right thing. By caring about the full story and what matters to customers, the level of impact a program manager has grows exponentially. Often I hear people bellyaching that “they [some other team] don’t get.” It’s a terrible excuse and those people are being lazy. Jocko & Leif tackle this directly in Extreme Ownership (a fantastic book on leadership) where they make the point that it is their job as leaders to help others, even other more senior leaders, understand the real situation and therefore make the right call. The same principle applies to the program manager, who necessarily is a leader. Whether its a superior, a peer, a direct report, or a partner, it’s your job as the owner to help them get it. Remember, it’s not about you. It’s about the person that needs to be convinced and framing and reframing the conversation until it makes sense to them. Everything a program manager does is around influence. In fact, you are kidding yourself if you believe you own a feature. After all, its the developers who, at the end of the day, type the code in and have the final say.
Nothing counts until it is in the hands of your [happy] customers.
So often I see teams celebrate when the API and the technology finally works (if they haven’t already celebrated and declared victory when the prototype started working). Heck, even when you start to get adoption, you are still miles from what most customers really want. I love the way that Simon Sinek phrased it in his TED Talk:
I love asking businesses, “What’s your conversion on new business?” And they love to tell you, “Oh, it’s about 10 percent,” proudly. Well, you can trip over 10 percent of the customers.
The real mass of customers don’t want to be on the bleeding edge of what’s new. Dev’s are the same. They want easy to consume, well supported, safe, almost brain dead ways of consuming your APIs. Anything less, and they would rather build it themselves since they know how to support it. If that wasn’t the case, then why are there so many string libraries floating around? Documentation, Samples, Tutorials – all are things many engineering teams view as a tax. Yet these are some of the things required to drive adoption across the chasm. Now, don’t confuse me with Ebenezer – of course you should celebrate when the prototype works, when the feature is complete, and when it is first shipped to customers. However, its important that when the party is over you set your focus beyond your toes and the immediate technology you are working on and instead focus on the horizon and delivering the whole product.
Influencing the Whole Product
I recently read Crossing the Chasm (which, I let it sit on my shelf for way to long). In it, Geoffrey introduces the concept of the whole product – the real set of products and services that a customer will need to employ to accomplish their ends. The idea is that the product that any one company typically produces is only a subset of what is really required. For example, even Microsoft, who has a massive array of products compared to all but a small handful of companies, can’t build the whole product of Windows. A big part of what people buy is the apps and services that thousands of other companies have built on top of the OS. In all but the rarest of situations, the whole product is out of reach of any one entity.
This brings us back around to the original conversation and the argument around span of control. Of course I don’t have the autonomy and control to employ the techniques and use the results to dictate every detail of the product. It would be naïve to think otherwise. Just consider, if the Apple’s, Google’s, and Microsoft’s of the world are all dependent on others to deliver the whole product, then why should any given feature owner think they are different. These companies all need to partner with other companies in order to deliver the results customers expect. Indeed, the life of a program manager or a feature owner is no different. They need to think through the end to end usage of their features and what customers will really need in order to be able to effectively use it. Landing a feature can’t be done alone. It requires partnering with a number of different people creating the other aspects of the product, some within and some outside the company.
So, do I have the span of control to employ the techniques? Certainly, not. But, do I have the responsibility and the scope of influence to do it? You better believe it.
If you found this useful, please help spread the word:
I always love connecting and hearing about what creative people are able to accomplish. So leave a comment with what you hope to go do or connect on Twitter. Or better yet, share what you have already been able to change or create.