thoughtbot recently hosted Boston Product Breakfast, an event where product managers can meet over food and chat about day-to-day challenges they face. We were joined by product managers from a range of companies, including HubSpot, Jibo, Kayak, Wayfair, and more.
During this event, the group discussed success (and horror!) stories regarding their experiences with building new products with their current teams versus buying or hiring consultants/contractors.
Much of the software that companies use is not what defines their business; you wouldn’t want to build a calendar and email platform because GSuite exists. The same likely goes for billing software, a real-time communication tool like Slack, a CRM, or other tools your team uses daily.
Many of our clients have, at various points in time, been caught in this trap; there’s an allure to building something from scratch to solve your particular problem. With that said, unless solving that particular problem is how you generate revenue, you’re probably better off evaluating a few existing tools and gathering feedback from the team to make a selection and buy externally.
Developing software is expensive. Solving problems that have been solved before, and on top of that having to build additional features, maintain the platform, and fix bugs on top of that, is very often not worth it.
- Is there a tool that solves 95% of what you’re trying to do out-of-the-box, and if so, is that remaining 5% necessary to give you an edge in the industry?
- Is your team equipped to support a new product long-term? If they’re managing business-critical software (e.g. billing, or real-time communication), are they able to fix issues on a moment’s notice?
If your team is focusing on an existing suite of products that do generate revenue, their availability may be a limiting factor in exploring new opportunities. We’ve worked with a number of clients who need to support existing products but have an idea they’re looking to validate and execute quickly. When this happens, hiring outside consultants may make sense.
The same holds true when a team has availability but lacks industry experience with a new approach; this might include making the shift from a web-based product to native iOS and Android apps, moving towards a research-focused product design lifecycle, or transitioning from a Ruby backend for processing millions of data points to a reliable processing pipeline built with Scala and Akka.
- Is your team able to absorb the cost of learning new technologies at the expense of feature development on other products?
- Are you willing to pause on potential products if your team isn’t available?
For each approach to introducing new software, it almost always boils down to cost, either to develop and maintain, or the opportunity cost when reallocating a team to a new venture. When expanding on a core product with your existing team and following a normal process, there’s no need to buy (because it’s likely nothing exists that solves the problem the way your business does) or hire consultants (because your team has the bandwidth and capabilities).