Every product team is faced with the build versus buy decision at some point. And it’s typically accompanied by a long list of considerations. How much time will take? Do I have the development resources? How much capital will I need? What will maintenance look like?
It’s a decision that has long-term implications, but the right framework can help make it a less intimidating process. In a Product Management Today webinar, Miles Robinson, Technical Project Manager for iFixIt, talked about setting SMART goals for projects that you choose to build in house or outsource to a third-party vendor.
What is the SMART framework and how does it help product managers answer the “build versus buy” question?
Miles Robinson: I like using old tools for new things. And the SMART acronym for goal setting is obviously where I have taken this and augmented from, but I’ve applied this to my decision-making in a way that it just allows me to tick the boxes.
SMART is comprised of these five considerations:
- Specific definition of the project scope and completion
- Measurement rules to monitor cost and success with enough time to adjust
- Alignment with your purpose and vision
- Resource considerations for short- and long-term needs
- Timeline of the project in the roadmap
The first two considerations—the specifics and the measurement—that’s the definition of a project. The orientation as to whether we want to do it in house or not is really going to happen in the alignment and resourcing questions. And it’s going to be augmented by our timing. This just makes things easy. Then, I use certain tools to make each one of these considerations or questions straightforward.
Starting with the first consideration—definition—what tools do you recommend?
Miles Robinson: The best tool I’ve come up with is the old elevator pitch. When talking to the executives, you’ve got six things to say and you’ve got 90 seconds to say them. They should understand what the situation is, why it’s important, and how you’re delivering value to the customer.
What are we proposing we solve? What is the actual solution? And then what is the expected outcome of that solution? Answering these questions allows us to set up metrics to measure that expected outcome, validate our results, understand whether our proposal meets the problem, and produce the solution we actually need. Finally, what needs to be done to make it happen? This is the plan for the actual project itself.
And this is one that I see a lot of conversation omit: What happens if we don’t do anything? For example, if you have a very volatile roadmap, then knowing what happens if you don’t solve these business problems helps to make the decision of which ones are more and less critical.
How do you limit the scope of your definition?
Miles Robinson: Some standard things that exist in the software world for definition translate very well for handling risk analysis when planning a project. First, unit test. This is looking at when you build something new: Have you disrupted everything that already works? Have you disrupted a process that was fine before? Next, code review. In software, this is when a senior person looks at a solution and makes sure the solution is valid, solid, and well architected. Know who your knowledge sources are and integrate them into the schedule. Being knowledgeable is going to be a key factor in the decision of whether you build or buy.
The next step is acceptance criteria. This is the specifics of actually delivering what you said you were going to. This is the one that people don’t usually have a problem with. It’s pretty straightforward. We know what our end goal is. Then, do a functional test to validate that our solution will work. We have to know our quality threshold as well. For instance, there’s a huge difference in user interface and the level of quality between medical imaging and a standard website. A website can be off by a pixel or two without an issue, but if one pixel is off on a medical screen, that could be a life and death difference.
Then there’s the non-functional test. These are the user or client needs outside of the specifics of the solution. If you’re delivering a solution to someone else, how does it integrate with their existing workspace? Understanding these elements is a really great risk aversion analysis. Your usability team will understand how to meet the needs in this area really well.
And lastly in software, is the product owner approval. Who is the approver? Who are the key stakeholders? With this, we have a definition. And this allows us to mitigate scope creep, but it also helps us mitigate some of the regular feature creep by looking at those boundary conditions. The greatest solution in the world, if it’s not useful, is not the greatest solution in the world.