What framework should I use to prioritize either dedicating engineering resources to build out product functionality or just using a 3rd party service?

Without full context, I will assume you are not a start up but rather a profitable business with growing revenue.

When considering whether to build, buy or partner (BBP), work with your team to put together a set of principles that are informed by your :

• vision and strategy
• differentiated core
• ability to deliver value to market quickly

Once you've identified the high leverage items that brings differentiated value, then work with your engineering team to model each of the 3 BBP options, and score them (doesn't matter how , just align on a framework). 

1. How quickly can you prototype and validate the solution with your target customer ?
2. What's the time to market for each option?
3. Which one delivers the highest value ?
4. For each option, what's the total cost of bringing it to market ?

I don't have a specific framework I use for determining build vs buy, but I've typically used a series of questions to help evaluate the decision:

- What is the problem you're trying to solve by building or buying?

- How strategically critical is that solution to your business? Is it something that could create a competitive advantage, help build moat against competitors? (If so, there is probably some risk in relying on a 3rd party.)

- What benefits come from buying? Does it significantly speed up your time to market? Are there long-term benefits or capabilities that a 3rd party vendor can provide beyond what you're immediately trying to solve for? (If either is yes, that may increase the value of buying a 3rd party solution.)

More importantly, look at other examples of companies having built vs bought and how they evaluated those decisions. One thing I love about the Internet is that there are tons of examples of companies having gone through this decisioning process, and how it worked out for them. I recommend checking out things like Ben Thompson's Stratechery blog, the Acquired podcast, blogs of companies you know have bought vs built in-house, etc.

I typically advocate for using full-time engineering talent on the most innovative features, hardest problems to solve and outsource to third party services for things that I can depend on, not require a ton of updates to, and save me money.

Your dedicated engineers are there because they're your most valuable resources - keep them engaged and excited by working on the most fun challenges!

It is important to consider the build vs buy decision where it makes sense as teams are often focused on building everything, resulting in inefficiencies and a lack of focus. While using 3rd party services can be a strategic move to accelerate your roadmap and free up resources and time, it is important to decide if it aligns with your long-term goals and strategy. To make the decision, consider the following questions with stakeholders

• Is the functionality core to your product and will it differentiate you in the market?
• Do you need out-of-the-box functionality or customizations?
• Are there industry-leading services you can use?
• Will using a 3rd party service accelerate time to market?
• What are the implementation and maintenance costs compared to building in-house?
• Will the 3rd party meet your user's service level expectations?

It is also wise to gather feedback from other customers of the service and the impact it had on their product and users, as these decisions require significant investment in capital, time, and effort.

When deciding between dedicated vs. 3rd party engineering, consider the following factors:

Final product experience: 

Evaluate the final product experience delivery to customers. For example, with a 3rd party tech team, does your design decisions make it a longer workflow for customers because of limitations of your tech stack? Is that an acceptable trade-off?

Time to market: 

There is still some cost to your internal engineering teams (onboarding, training, code reviews etc) when using a 3rd party tech team. Consider if this is a short-term vs. long-term strategy. Sometimes for business reasons, an important project acceleration is required. A long-term strategy is more beneficial if this is not just for a project, but rather an investment for continued roadmap acceleration. 

Cost-benefit analysis: 

Consider roadmap feature time to delivery and accelerated business outcomes between the two options vs. cost implications (incremental 3rd party spend). Benefit vs. cost analysis will be helpful to determine whether to use only your dedicated engineering team or pick a hybrid of internal and 3rd party tech team for faster time to market.

My two go-to frameworks are MoSCoW and RICE. The first focuses more on prioritization based on the importance of features, while the latter emphasizes prioritization based on the Reach, Impact, Confidence, and Effort involved in each option.

In your specific situation, I'd start by outlining a list of user stories and then using one of the frameworks above to compare build vs. buy solutions.

At our company we are transitioning from a quarterly planning cycle to an 'agile' approach. With the advent of ChatGPT and accelerated product development cycles across the industry it has become challenging to meaningfully progress features when they need to be planned months in advance. Here is a short brief on why we choose to make this shift.

• Shortfalls of Quarterly Planning:

  • Lacks flexibility and responsiveness to change.

  • Locks teams into rigid commitments, making it difficult to pivot as customer needs or market conditions shift.

  • Relies on long-term assumptions that may become outdated, leading to misaligned priorities.

  • Can result in wasted resources if original assumptions or priorities no longer hold true.

  • Challenges in addressing unforeseen issues promptly or capitalizing on new opportunities.

• Reasons for Shifting to Agile:

  • Enables frequent reassessment of priorities and resource allocation.

  • Supports incremental delivery aligned with the latest customer feedback and market insights.

  • Allows for dynamic adjustments to near-term objectives as new information emerges.

  • Increases adaptability by focusing on shorter planning cycles, reducing the risks tied to long-term fixed commitments.

• Capacity Planning in Agile:

  • Avoids detailed capacity planning for items more than six months out, as these priorities may shift.

  • Emphasises flexible resource allocation based on immediate and evolving needs.

  • Quarterly roadmaps can still provide high-level guidance, but agile enables fine-tuning and reprioritisation as needed.