Slides Scott Stokke recently used in his discussion w/ mentees of The Product Mentor. Synopsis: Evaluate between building internally or buying a software or service for your platform or feature. Continuing discussion on how to get buy-in from stakeholders. The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…Better Decisions. Better Products. Better Product People. Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community. http://TheProductMentor.com

1. MANAGING THE BUILD /
BUY DECISION
Scott Stokke
Director, Product Management
First Advantage
scott.stokke@gmail.com
linkedin.com/in/scottstokke

2. 2
• Recovering Developer
• Product Manager / Director
– Startups
– Fortune 500
– B2B / B2C
– Director / Business Owner at First Advantage
• MBA
WHO AM I?

3. 3
WHAT ARE WE TALKING ABOUT?
Do you build it yourself? Do you buy from someone else?

4. 4
• No time constrains on your project - (ha!)
• Technology is a strategic differentiator
• Technology or process is core to your offering
• Technology hasn’t been built before (or no vendors available)
– Not all features are in off the shelf software
• You have an available technology team (or one can be made available)
HOW DO YOU DECIDE TO BUILD?

5. 5
• Technology or process is a commodity
• Provides no differentiation
• Not a core competency
– Don’t want it to become one
• Time constraints on project (time to market)
• Lack of expertise in house
HOW DO YOU DECIDE TO BUY?

6. 6
BENEFITS
Build
• Control your own destiny
• Control all features and timing of
features.
– Custom processes are easy to
solve.
• Competitive Advantage
– No one else has this Feature
Buy / Partner
• Complete product immediately
– Reduced time to market
• Maintenance and updates are
done without intervention
• Reduced costs
– Ability to use resources in other
places

7. 7
POTENTIAL ISSUES
Build
• Resources for maintenance and
updates.
– Increased costs and expanded staff
• Build / maintain specialized
expertise in product
• Time to market
– Usually need more time to get
project done
Buy / Partner
• Product many not have all the
features you need
– Need to influence partner roadmap
• May need to integrate
– Need to budget for cost of
integration
• Partner business viability
– How long will partner support this
product?
• Are competitors using this
product?

8. 8
• Make sure you’re clear on the problem you’re solving
– Is there an MVP? Are there Intermediate steps?
• Do you’re diligence
– Understand the importance of what you’re trying to do
• Make an assumption and test
– Run the numbers
– Get quotes
– Test drive
HOW DO YOU DECIDE?

9. 9
• Beg
• Business cases
– Cost benefit analysis – Doesn’t have to be fancy!
– ROI, if proven, makes the difference!
• Organizational aptitude
– Is your organization a “build it here”?
HOW DO YOU GET WHAT YOU WANT?

10. 10
• Lots of options – depending on the vendor
– Negotiate!
• Smaller, nimble vendors have more flexibility
– Exclusive contracts
– Code escrows and customizations
• Be Creative!
– Incrementally buy what you need (users)
– Delayed payment terms
– Joint go-to-market plans
• Leave yourself some options
– Don’t sign that 10 year deal
BUY – HOW DO YOU MAKE IT WORK?

11. 11
Problem: Personal finance application. Help consumers budget and
save.
Issues:
• Need to test market quickly
– Space is crowded
• FinTech solution new business problem, no current expertise in the
space.
CASE STUDY – FINTECH STARTUP

12. 12
CASE STUDY – DOCUMENT MANAGEMENT COMPANY
Problem: Document Management company adding workflow to
application to allow users to approve / route / report on documents
Issues:
• Company feels this feature will be a differentiator
– No players have this feature
• Opens up the company to new potential verticals when feature in place
• Need to get to market fast

13. 13
FINAL THOUGHTS
• Not always a clear answer
• Understand the scope of the problem
– Validate Assumptions
• Know your organization
– Are they predisposed one way or another?
• Keep end goal in mind
– What you’re trying to accomplish should drive your project

14. 14
THANKS!
Scott Stokke
scott.stokke@gmail.com
linkedin.com/in/scottstokke