the role of product management within the product team
Origin: What do open source product teams do? • Opensource.com
EXCERPTS:
…a subset of tasks that are applicable in open source products:
- Market problems: Talk to customers and figure out what they need
- Product roadmap: Determine what features will be added to the product and when
- Build: Invest in building technology in-house
- Buy: Purchase technology from another company
- Partner: Deliver a solution to a customer by leveraging a partner’s technology
- Pricing: Determine the price
- Packaging: Determine what’s included in the price
- Channel training: Train the salespeople so that they can educate potential customers
Build, buy, or partner?
Which is more important, the business need or the technology? This is probably the classic paradox of business strategy. The answer is neither. Execution is what matters. The product management team is tasked with creating and retaining customers. This can be done by building technology, buying technology, or partnering to acquire technology or services that, when combined, provide value to customers.
With traditional proprietary software products and services, this could mean building, buying, or partnering for a foundational piece of software, like a database. With products built on open source software, this can be thought of as choosing an open source project as a supplier. The purchase is made by contributing engineering time, code, documentation, testing, infrastructure, etc. Because open source is not free as in beer, somebody has to write it, test it, document it, etc. It’s very difficult to provide value to customers if you don’t contribute upstream.
This combination of built, bought, and partner-delivered capabilities is what differentiates a product, whether open source or proprietary. Proprietary licensing does not differentiate a product. Let me repeat: proprietary licensing does not differentiate a product. People confuse proprietary licensing with providing value to a customer. Proprietary licenses are a perfectly valid and useful way to monetize users, but they do not provide customers with more value. Licenses do not create value; they help extract it.
Types of products built on open source
Most modern software products are delivered by adding new value to the value provided by the open source supply chain.
This could include extra downstream testing, documentation, quality engineering, performance testing, security testing, industry certifications, a partner ecosystem, training, professional services, or even extra proprietary code not included upstream (open core). By considering this new model, many of the old debates about open source can be clarified:
• Open source products: The entire supply chain of code that goes into the product is open source.
• Open core products: Some of the supply chain of code that goes into the product is open source while other parts are proprietary.
• Paid software-as-a-service products: The supply chain of SaaS products can be made up of open source languages and libraries, while the business logic built in-house is often proprietary.
• Free SaaS products: essentially the same as paid, instead of tightly controlling the pricing and packaging, the product is monetized through user data or advertisements.
• Cloud providers vs. software vendors: The recent interest in and creation of new quasi-open source licenses are better understood by thinking of open source as a supply chain and SaaS as a pricing and packaging model.
• Open source as awareness: In this model, the buzz around the upstream project is used to deliver awareness for the products built on it.
• Open core as marketing: …a step further than open source as awareness. A single vendor almost always controls the upstream open source projects that go into open core products. … Open core products advertise that they include the open source project to provide core value propositions.
The supply chain
Like an automobile, the sum of a software product is greater than the individual parts. When a manufacturer delivers a car, it’s more than its parts. Most of the parts aren’t differentiated between vendors. Software products, especially ones built on an open source supply chain, are no different. Product management needs to differentiate their products from the underlying software components in the supply chain. The value of a software product is a layer of differentiation built on top of a supply chain of dependencies. This value is what product management must focus on.
Differentiated value
Product management is not about picking and choosing what bugs are fixed upstream or downstream. It’s not about holding back enough value in the open source project so that users purchase the product. It’s not about coming up with special licenses to monetize an open source project’s user base. It’s about creating differentiated value that customers will pay for. It’s about listening to their needs, internalizing them, and knowing them intimately. It’s about influencing a supply chain, switching supply chains, and building a partner ecosystem that gives your product gravity.
Product managers who think about differentiated value on top of an open source supply chain can easily answer the following questions:
- As an open source product manager, should I attend conferences for the upstream projects?
Sure, because it’s like attending a trade show for one of your suppliers. - How should product management handle a situation where the upstream project isn’t delivering what their customers need?
Add more investment. If the open source community is healthy, it will produce what you need. - What should product management do when an upstream community is struggling with contributions or is unhealthy?
The same thing that a manufacturer would do if their supplier lost contracts with their two biggest competitors because they were failing: switch suppliers.
In the next article, I will delve into the distinct value created in products, focusing on the value that upstream projects can’t provide. If product management is done well, there is no unnatural tension between upstream suppliers and downstream products. When done right, both the upstream projects and downstream products create unique and differentiated value that satisfies the needs of users and customers alike.