Build a product management process that ensures you're building the right thing—researching customer problems, prioritizing features, and managing the roadmap systematically.
There are two primary functions in a small dev team: Product Management and Product Engineering. The Product Management team is generally led by a Product Manager and is focused on researching and prioritizing what to build. The Product Engineering team is tasked with engineering both the process and the technology to deliver the product. In other words, the Product Management team is charged with building the right thing, and the Product Development team is charged with building the thing right.
Dev is a highly process-oriented activity. Golden Section believes your company is much stronger when the processes are designed and in place and you've clearly delineated who is responsible for what activity. Having a great process can help minimize risks and prepare for unforeseen challenges once your development goes full speed.
The goal: Develop a product management process to ensure you are building the right thing.
How can Golden Section Assist?
Role and Responsibilities of a Project Manager: A Product Manager bridges market signals and the engineering team, translating customer pain and market opportunity into a product vision and roadmap. He is often an industry expert with a clear understanding of the industry's workflow, common issues and general environment.
A Product Manager is responsible for establishing product vision and features, setting a roadmap and feature definition for each product or product line, and then assuring product/market fit. Generally, the Product Manager sets the priorities for the dev team and interacts frequently with the Software Architect and Lead Engineer to determine the technical feasibility and effort level for new projects. Here is a top-level view of the responsibilities of a Product Manager:
An Overview of the Project Management Process:
The product management process is the entire process of visioning, planning, executing, and exiting a product. In the era of product led growth, the definition of what involves the 'product' has expanded. The product manager is responsible to manage the product management
Creating a product is chaotic. Nothing about it is smooth or easy. Good products require dealing with the chaos; embracing it in the right way and pushing through. But not all chaos is the right kind of chaos.
When Nietzsche uses the word chaos he is not referring to disorder but rather the space between potential and creativity. In our post-modern Western context, however, the word 'chaos' embodies both disorder and the creative potential to which Nietzsche refers. Poor process, unqualified personnel, logical errors, these are all examples of ineffective chaos (e.g. disorder). Embracing it doesn't give birth to a dancing star, it gives birth to the leviathan -- the embodiment of 'disorder' chaos.
Faced with this tension, how can an enterprising founder navigate the product development process to give birth to the dancing star without creating the leviathan? How can one know what chaos to embrace and what chaos to avoid? These are crucial questions.
Good chaos is the pathway from the safe status quo of now to the unrealized potential of your creativity. Like John Lewis said, "get in good trouble" in order to form a more perfect union. But too often, founding teams get into the wrong trouble, and stuck in ineffective chaos, give birth to leviathan instead of a dancing star.
Golden Section has partnered with more than 350 founders across more than 50 industries to navigate this crucial question. Getting it right means the cost to birthing the dancing star is significantly lower than teams that fumble around in the dark before finding it. Of course, companies that end up birthing the leviathan never survive so comparisons are infinite.
Strategy - Conceive and Plan
So many products begin without proper planning. In some ways this is inevitable. No founder knows exactly what the end-product should look like when starting out. The customers will have a say in what features matter most and ultimately whether the product has value. But the inevitability of future change does not excuse starting out with no expectation of an end-result.
Creating a product charter or vision document is a good way to fight against this urge. It outlines the things that are important to consider. Some of these things are unknowable at the beginning. For instance, which features the customers will like most. Others are more tangible. For instance, how much downtime can customers in this industry tolerate or what DevOps expectations of reliability and performance should be pursued. These represent more tangible goals that should be a part of every product vision.
At Golden Section we recommend the following checklist to assess whether a product vision document is sufficient:
Diving into development to build a product without a minimum vision document that satisfies the checklist above is sure to create the leviathan rather than a dancing star. Golden Section project managers and technical team leads have witnessed teams still reeling from the negative side effects of a hasty start years after product launch. This is one of the most critical points of leverage in an R&D organization.
At Golden Section, we recognize that the non-technical founders will often feel lost by the terminology of product development and require help. We have oriented our engagement structure to provide experienced product management talent to our clients to ensure proper planning. This saves smart founders millions in incentive equity and compensation where others struggle to hire technical leaders to plug this hole.
Strategy -- Product Roadmap
Listening to 'the wind' might work for Cat Stevens, but it doesn't work for a multi person engineering organization. An organization is made up of individuals pursuing a common aim. This common aim needs to be defined. For an R&D organization, this is a product roadmap. It specifies the sequence in which the product vision will be realized.
For early stage teams, a roadmap might seem like a useless exercise designed to make investors happy and check a box for funding. This couldn't be further from the truth. It ensures that everyone on the team (even if the team is just two people) understands the order of priorities.
The roadmap must be accompanied by a product roadmap meeting in which the key constituents of the company can vie for their perspective of what is most important. Sales will push for features, dev-ops and support for reliability, and the executive team will push for perceived competitive advantages. At the intersection of these competing tensions is the dancing star. When one of the voices is too loud or too intransigent, the leviathan starts moaning.
When 'the wind' controls this process, the result is chaos. Experienced founders have witnessed the chaos created by a roadmap hijacked by the sales team. This is one of the common ways a process results in the leviathan. The product initially may succeed in achieving sales, but the lack of reliability results in a hostile customer base.
Conversely, technical founders can often fall into another ditch by continually building reliability into the product at the expense of customer-facing features. This results in no
sales which is just as bad. Mediating this tension is the role of the product roadmap process.
There are two ends to the spectrum of poor product control. On one side of the spectrum are teams that follow the age-old mantra that "the squeaky wheel gets the grease." In these organizations the product creation process is hijacked by
self-interested sales team members and loudest customers. As a result, the engineering team is forced to work on urgent but not important issues. This puts the product in a continual state of catch up.
The other side of the spectrum can be best illustrated by what Alan Cooper described in his book: "The Inmates Are Running the Asylum." On these teams, engineers are deciding what to build. These teams build products that have a lot of cool new tech features, but they don't meet customer expectations or provide meaningful value.
The mission of product management is to achieve the balance of above two tension. Always work with customers and the tech team to find product market fit, shield engineers from sales, and help the engineering team focus on addressing the important strategic items one iteration at a time. The best way to achieve this tension is through a well-controlled roadmap.
At Golden Section, we recommend a product roadmap process with the following minimum components:
There are two primary functions in a small dev team: Product Management and Product Engineering. The Product Management team is generally led by a Product Manager and is focused on researching and prioritizing what to build. The Product Engineering team is tasked with engineering both the process and the technology to deliver the product.
Build a product management process that ensures you're building the right thing—researching customer problems, prioritizing features, and managing the roadmap systematically.
Build a product management process that ensures you're building the right thing—researching customer problems, prioritizing features, and managing the roadmap systematically.
The mission of product management is to achieve the balance of above two tension. Always work with customers and the tech team to find product market fit, shield engineers from sales, and help the engineering team focus on addressing the important strategic items one iteration at a time. The best way to achieve this tension is through a well-controlled roadmap.
There are two primary functions in a small dev team: Product Management and Product Engineering. The Product Management team is generally led by a Product Manager and is focused on researching and prioritizing what to build. The Product Engineering team is tasked with engineering both the process and the technology to deliver the product.