A quick intro to the Build, Buy, Acquire decision for Digital Product Managers.
Presentation excerpt from Udemy course "Digital Product Management" http://udemy.com/digital-product-management
2. Theory of Constraints
You’ve got limited time and money.
When considering building, buying or
acquiring, you need to consider what
core strategic value you need to
provide to survive.
Example: You can buy or rent
ecommerce software for goods you’re
selling. But if you’re the ecommerce
software vendor, chances are you
need to own and manage your
codebase yourself.
3. Coase & The Nature of the Firm
"The Nature of the Firm,” an essay written in 1937
attempts to explain why people come together to
form businesses.
Part of the economic reason for doing so has to do
with transactions costs, originally discussed by
John Commons in 1931.
4. Transaction Costs
Transaction costs include any costs
associated with participating in a
market. Examples:
Search & information.
Bargaining.
Policing & enforcement.
You could make your own
paper clips, but why would
you?
5. So What are Some Considerations
Are you expanding into a new market or product area?
What is your Go To Market (GTM) timing?
What kind of team do you have to support intended
growth?
Do you have the infrastructure, (financial, management,
technical expertise), to support your goals?
6. Cost / Benefit Analysis
What is the final Net Value for Each Option?
Include Time Value of Money if the different options have significantly
different time to market release dates.
People tend to underestimate costs.
Build: Costs for new equipment, personnel, training.
Buy: Overhead to manage partner(s), re-work from errors / communication
problems. Lack of control. Delays.
Acquisitions: Costs for legal/financial
support.
Also, there will always be:
Overhead, financial integration.
7. Why Build?
The Value being created is core differentiator.
Legal or Regulatory needs necessitating complete assurances of
performance. (Or perhaps security.)
Necessary Customization or performance simply is not accessible in
existing marketplace.
Needed Availability / Quality assurances can’t be assured by others.
Branding. Consumers may not accept third parties if they become
aware of them.
Using suppliers may benefit suppliers more. Or competitors over time.
Concerns about piracy via outsourcing.
Full ownership and ownership of Intellectual Property.
8. Why Buy / Outsource
Products/services not stategic to the firm.
Fixed costs of production undesirable.
Others are more efficient producers.
Leverage others’ experiences.
Allow for switching of sources or multiple
sources.
No choice due to limited supply of talent,
access to resources or technology.
9. Why Partner?
Reduce marketplace entry risk by spreading risk and testing the market.
Partner may have needed or desired infrastructure already in place.
Partner may have offering ancillary or superior to your own. (E.g., you
have a great module that fits into a larger scope health care package.)
Partnering should decrease speed to market.
May need technical, production, logistics, or sales partners.
Partner has market power or best of breed position you won’t achieve
anytime soon, and customers buy best of breed in this marketplace.
10. Don’t Forget About Ongoing Costs
For some products, perhaps especially software, there are
often ongoing maintenance costs.
Over time, these costs can grow to where it may make
more sense to buy or rent rather than build.
Maybe you can build a quickie
sales management system yourself.
But how much do you think you’d
spend to re-create features on
Salesforce.com?
11. Concerns
Whatever the choice, how will the
choice affect:
Your customers.
Existing partners.
Employees.
Regulatory agencies.
Other stakeholders?
12. Everything is a Mashup
Currently, most digital business ecosystems have a rich offering
of suppliers and services.
Not very long ago, you had to build your own Customer Relationship
System. Now? Not so much. Accounting systems? Advertisement
delivery? You’re going to buy partner services for most of these.
Even if some lack needed functionality, many expose their APIs so you
can fill in gaps.
You always need to return to the questions…
“What is my core value creation capability?”
“Should I be expending precious resource on creating this myself?”