I've seen lots of teams and companies try to overload the product management role onto other disciplines. Often the CEO, CTO or a set of developers, or in best case, designers take it on. The problem with doing this is conflicting interests.
The CEO is interested in bringing his or her vision to life, yes, but often doesn't have time to deeply understand the customer, aside from themselves. This often results in a product that serves one person, or a set of people that are almost identical to the CEO in desires. With so many other demands on the CEO such as sales, evangelism, team building, financial analysis, and market analysis, the CEO can't do it all. This leads to developers coding ahead of the CEO and eventually into developer driven design. While it's great to have input from the CEO, product management should quickly be handed off to a dedicated resource.
Technical roles such as developers or CTOs often want to take on the product management role, or often surge forward when the CEO is busy with their own ideas. They are focused on the technical debt and technical challenges they see. This will no doubt increase the value of the product, but usually not in ways customers see it. Customers don't see changes in framework, or how quick your continuous integration is, or updated support tools. Developers often direct products again in the ways of cool tech to work on, or hard technical challenges, without actually understanding what impact those parts of the product will have on the customer. In many cases, such as a changed out framework, there is no impact to the customer, and months pass without bringing value to the people who are paying.
The closest role that can help shape the product is a pure Designer; more so if that Designer is product minded. Designers bring a lot to the table regarding ease of use and aesthetics of the product. However, they tend to focus on design principles and solving the problems at hand. Designers are fantastic for taking part(s) of a long term vision and executing on the near term, but many designers won't think about the long term goals and product strategy. They focus in the weeds of what's in the next release, does this have to be a text box, or a drop down, and where does it go? While design execution is extremely important, it doesn't satisfy the need for a cohesive long-term strategy for the product.
The product manager role, separated from other disciplines, enables a long term plan by defining a story. Product management also brings the customer voice to the table, it leverages customer feedback, and other information to build a product road map, and product goals. Product management focuses designers and accelerates developers on what's important now, what to plan for in the near term, and what to account for in the long term. Product management also has the ear to the ground for changing market conditions, and can help adjust the plan when the long term market is adjusting.
Input from the CEO, developers, designers and the rest of the company is still important, but a single person to own the strategy and vision will build a cohesive product and ultimately save time, and delight customers with a plan in the long run.
My favourite example of engineering run design is Windows Update from Microsoft. Albeit Windows is a large platform, and there is a strong desire to both keep Windows secure, while at the same time make it easier to maintain, there is a clear missing voice of Product Management.
I can tell this is engineer driven because the easy engineering road is taken, and it's irritating to customers. While the concept of "Patch Tuesday" was defined around this made it easier for system admins to plan for patch updates, it's terrible to think that this concept even has to exist. The personal computer should be doing whatever it can to make the person successful. The person shouldn't have to wait on maintenance, or updates when they want to use their computer, those should happen in the time the person isn't around. I mean humans do sleep for 6+ hours a night, more than enough time for computers to maintain themselves.
The reason that a reboot is intrusive is because no one or no team at Microsoft has taken the effort to figure out dependancies between components, as such when taking down a small service to update it. The teams at Microsoft have no idea what they might be breaking in other teams services, so they reboot the computer, a.k.a the easy path. Then once they know things are patched, they start all the services, when in reality, it should be something that the computer can just save the users state, restart a small service, set of dependant services or apps, and be invisible to the end user. If there was serious Product Management on Windows Update, and in the case of large enterprises, that Product Management team had executive support (aka, Satya or EVP of Windows, Terry Myerson), things will change for the better for the end user, to the tune of "Wow, my Windows computer never reboots!"
The CEO is interested in bringing his or her vision to life, yes, but often doesn't have time to deeply understand the customer, aside from themselves. This often results in a product that serves one person, or a set of people that are almost identical to the CEO in desires. With so many other demands on the CEO such as sales, evangelism, team building, financial analysis, and market analysis, the CEO can't do it all. This leads to developers coding ahead of the CEO and eventually into developer driven design. While it's great to have input from the CEO, product management should quickly be handed off to a dedicated resource.
Technical roles such as developers or CTOs often want to take on the product management role, or often surge forward when the CEO is busy with their own ideas. They are focused on the technical debt and technical challenges they see. This will no doubt increase the value of the product, but usually not in ways customers see it. Customers don't see changes in framework, or how quick your continuous integration is, or updated support tools. Developers often direct products again in the ways of cool tech to work on, or hard technical challenges, without actually understanding what impact those parts of the product will have on the customer. In many cases, such as a changed out framework, there is no impact to the customer, and months pass without bringing value to the people who are paying.
The closest role that can help shape the product is a pure Designer; more so if that Designer is product minded. Designers bring a lot to the table regarding ease of use and aesthetics of the product. However, they tend to focus on design principles and solving the problems at hand. Designers are fantastic for taking part(s) of a long term vision and executing on the near term, but many designers won't think about the long term goals and product strategy. They focus in the weeds of what's in the next release, does this have to be a text box, or a drop down, and where does it go? While design execution is extremely important, it doesn't satisfy the need for a cohesive long-term strategy for the product.
The product manager role, separated from other disciplines, enables a long term plan by defining a story. Product management also brings the customer voice to the table, it leverages customer feedback, and other information to build a product road map, and product goals. Product management focuses designers and accelerates developers on what's important now, what to plan for in the near term, and what to account for in the long term. Product management also has the ear to the ground for changing market conditions, and can help adjust the plan when the long term market is adjusting.
Input from the CEO, developers, designers and the rest of the company is still important, but a single person to own the strategy and vision will build a cohesive product and ultimately save time, and delight customers with a plan in the long run.
My favourite example of engineering run design is Windows Update from Microsoft. Albeit Windows is a large platform, and there is a strong desire to both keep Windows secure, while at the same time make it easier to maintain, there is a clear missing voice of Product Management.
I can tell this is engineer driven because the easy engineering road is taken, and it's irritating to customers. While the concept of "Patch Tuesday" was defined around this made it easier for system admins to plan for patch updates, it's terrible to think that this concept even has to exist. The personal computer should be doing whatever it can to make the person successful. The person shouldn't have to wait on maintenance, or updates when they want to use their computer, those should happen in the time the person isn't around. I mean humans do sleep for 6+ hours a night, more than enough time for computers to maintain themselves.
The reason that a reboot is intrusive is because no one or no team at Microsoft has taken the effort to figure out dependancies between components, as such when taking down a small service to update it. The teams at Microsoft have no idea what they might be breaking in other teams services, so they reboot the computer, a.k.a the easy path. Then once they know things are patched, they start all the services, when in reality, it should be something that the computer can just save the users state, restart a small service, set of dependant services or apps, and be invisible to the end user. If there was serious Product Management on Windows Update, and in the case of large enterprises, that Product Management team had executive support (aka, Satya or EVP of Windows, Terry Myerson), things will change for the better for the end user, to the tune of "Wow, my Windows computer never reboots!"
