Skip to Main Content

Build vs buy: How one solution delivered 70-80% functionality at a fraction of the cost

The brief

Define an MVP to pilot

For nearly 40 years, our client has been a champion for quality early learning and care, focused on closing the opportunity gap for our nation’s youngest learners. The organization had initially launched a platform intended to be the single online destination for early childhood systems leaders to connect, collaborate, and exchange knowledge.

When they first approached us, they wanted a partner to help them more clearly define what a minimum viable product (MVP) should look like based on their target personas, user needs, and feature sets. Once they had clarity on what the MVP should include, they planned to bring it to market.

Their team decided to work with TXI in part because we suggested a slightly different approach. Because they had well-defined personas, rather than focusing on generating more of them, we helped bring focus to the jobs those personas needed to accomplish.

We explained how our product innovation approach would guide us in gathering and analyzing user input, then using it to define the necessary components of an MVP.

The challenge

"Steal shamelessly, share seamlessly"

In one early call, a client team member characterized the ideal state of the platform they hoped to build as one that would let users “steal shamelessly and share seamlessly.”

With that as a guiding principle, we talked to several likely users of the platform to get a sense of their daily work, their pain points, and the capabilities they wished they had — i.e., what they’d want to share and what they’d want to steal. We also spoke with internal client stakeholders and leaders to understand where they saw the biggest opportunities.

The client’s team members were invaluable partners in our product innovation work: the early childhood space is a complicated domain rife with lingo, acronyms, and nuanced distinctions. We collaborated with them throughout the process to ensure we had adequate subject matter understanding to scope a viable solution.

The client team also had a large body of existing research and knowledge. Part of our work was to determine what in that body we should build upon and what we should reconsider.

As our research got underway, we recognized that one major challenge lay in the sheer variety of experiences among potential platform users: in addition to having vastly different roles, they had access to vastly different resources and services, depending on where they were located.

The team’s passion for driving change was critical to the success of the project. They worked cohesively, making aggressive strides to enhance the product’s experience for users. This required a consistent and deliberate effort to ensure the product was accessible and valuable to the community.

The Solution

Define what the platform should do based on user needs

As we spoke with stakeholders (internal and external), we sketched visualizations of their relationships to align our team and the client team on exactly who we were building for. We also used insights from the conversations to ideate toward a model for the kinds of jobs coalition leaders do to strengthen their systems.

This approach––letting user conversations guide iterative versions of a product––is a core part of product innovation. In the words of our head of design, it can feel a bit like building cubes from fog.

We emerged with a clear sense of who the highest-impact users were (both internal and external) and what the platform’s highest-impact use cases would be. This enabled us to craft a comprehensive vision of both the short-term MVP and a long-term product evolution.

The Outcome

A research-backed concept with two viable paths forward

Once we had clarity on what the platform should be, we were able to provide a rough prototype, as well as estimates of time, effort, and cost associated with building vs. buying the real-world version of the platform.

For the “buy” option, we recommended an off-the-shelf solution that could accomplish roughly 70 to 80 percent of the functionalities we’d scoped, for approximately 25 to 30 percent the cost of building a custom solution. What's more, the “buy” solution would let the client implement the platform in six to 12 months rather than the two to three years that would be necessary for a custom build.

If you’re struggling to decide how to tackle a big problem or you’re not sure how to evaluate the many opportunities before you, we can help. Get in touch to learn more about how our product innovation approach to research and design can point you on a clear path to success.

Let’s start a conversation

Let's shape your insights into experience-led data products together.