How to align Product Management and Engineering on build vs. buy decisions

When it comes to a build or buy decision, product managers and developers can have dramatically different points of view. The two teams sometimes, but not always, find alignment on the decision. So how do product managers gain buy-in from developers on a build versus buy decision? Rich Mironov, author of The Art of Product Management, served as a guest speaker for a recent Sendbird webinar where he suggested a strategic approach to find some middle ground. In this blog post we’ll summarize the key takeaways and great Q&A between Rich and our audience. Watch the full replay of the webinar here.

Rich’s key takeaways

1. Engineering and product have different points of view – “can we” versus “should we.” Developers often start by asking how easy/hard a new feature will be, and whether it presents interesting problems worth solving. Product managers often start by asking if that feature will visibly differentiate their product versus competition, or get customers to pay us more, and what else is urgent at the top of the backlog. Product managers need to lead with empathy, but also help developers focus their time and energy on what matters the most to customers.
2. We often confuse strategic and generic capabilities. Build only what is strategic to your business. Buy or license everything else that you can. What is strategic for you to build is determined by what differentiates your product — the reason why customers buy you.
3. Easy to underestimate complexity, especially on things we don’t know very well. We might not understand what it will take to maintain and update what we build. Plus, we forget that every development team is over capacity with an infinite backlog.
4. “Buy” isn’t a critique of the dev team, but can feel that way. We want to focus developer effort on what brings customer joy and drives revenue. Customers will love what we do when we are working on the pieces that they see, or which truly set our product apart.

Q&A with Rich

What is your advice on getting buy-in from an outsourced engineering team?

Outsourced engineering teams are often worried that we are going to replace them,or cancel them or stop working. That is a reasonable thing to worry about. On the other hand, the backlog takes us to 2045. If we’ve got an outsourced team that we trust and like and are doing good work with, I’m pretty sure I have a list of things as long as my arm that I need them to do. I would reassure them that there’s more work than we can ever finish… here are six other things that we desperately need you to work on.

How do we agree as a team on what is strategic?

As a team, acknowledge that a lot of product roadmap items are important and necessary, but they don’t all have to be differentiated. For example, ease of authentication is important when you are building integrations with external systems. If I buy a login management system from an outside vendor, I know they have already addressed the problem of cross-application authentication. They do this all day long. If I were going to build that myself, I would duplicate all of that work. Your customers need it, but there is no differentiation in how it’s done. You just need it to work. I would rather borrow the vendor’s intelligence and do as little as possible on it and have it work rather than have my team spend a year having to learn all about that area.

Let’s take CRM as another example. There are companies that sell CRM and companies that use CRM. We are going to be a company that uses CRM so we are going to choose the fields that we need and configure they system to our use case, but we don’t need to build a CRM. We’d much rather license one, have it up and running in a day, and spend the next few months figuring out what customizations we might need.

Why would I buy from a vendor who offers way more features than I actually need? Wouldn’t it be better and cheaper to just build just what I need?

Generally I expect vendors to have different packaged editions of the product they sell from basic to more advanced. It’s hard to know what our required features are if we are new to the space. What often happens is we build the few features we need, and then it turns out there are two more features under that we need, and then six more features and so on. If I’m competing on the basis of how good my CRM is, I might build one. But most companies in the world should go buy one. I’m pretty sure as soon as I tell my marketing team that we built a CRM system, there is going to be this parade outside the product manager’s office with just one more feature each from every single person in marketing. We are going to find ourselves creating a lot more than we originally thought.

How do low-code solutions factor into the build versus buy decision?

Low code solutions highlight a new possibility of buying to build without a developer, but I think you have to try it and ensure it delivers the function needed. Low code solutions usually take a template approach. These solutions make sense for quickly automating internal business processes by a non-technical business user. But I’d be cautious about low code solutions that affect what my customers are going to see because they are going to experience it. Make sure the low code solution looks like you and fits in with the other things that you are doing.

When you decide to buy, how do you best evaluate solutions?

Many vendors offer some type of trial or pilot period that allow teams to get something up and running with little investment. It’s good to trial from multiple vendors and compare. Any vendor who doesn’t allow you to see or experience the product yourself probably isn’t one you want to work with. More importantly, have someone in the evaluation cycle who is actually the person who will perform the implementation. Having a bunch of product and marketing folks telling engineering what the best tools are, well that’s a waste of time and effort in all directions. Determine the person at your company who is really going to put their hands on it. Can you get them the API docs and other resources they need to feel comfortable with a solution? If not, no one should care what product management thinks.

Who should make the final decision on build vs. buy?

The head of product and head of engineering have to be shoulder to shoulder when they are in public on all important issues. I never throw my VP of Engineering under the bus, and I expect the reverse to be true. We have knock-down, drag-out arguments when the door is closed and no one else is around. When we finally get to a decision, it should be one that we all ratify — we stand up and sing the song together and tell everyone how good it’s going to be. There cannot be any intramural fighting. We made a decision, and we are going to live with it now. Product management has an obligation to stand in front of engineering on ths one. We own the call – whoever made it. We own the mistake – whoever made it. It’s my job to be the umbrella for engineering, not the funnel. To learn more about this topic from Rich, read his recent blog post Shoulder To Shoulder.

Sendbird is gathering market research on the build vs. buy topic. Complete this quick survey and receive a $10 gift card to your online vendor of choice. We’ll be sharing the results soon!