A Common MVP Evolution: Service to System Integration to Product

It’s not uncommon for a startup’s offering to evolve from service to system integration to product. Here is an explanation for the reasons and benefits.

A Common MVP Evolution: Service to System Integration to Product

MVP evolution: service to system integration to productOne common approach we see is for bootstrapping teams that have a basic understanding of customer needs to start by offering a service. Once they get uptake on their service offers they start to take advantage of existing solutions prospects are using to create a “system integration” or extension offering. For example if your goal is to replace Excel where it’s being used for a particular purpose, first offer an Excel template. This is more compatible with current practice, is easier for prospects to trial, and is also easier to iterate on than a fully coded solution. Once they get uptake on the system integration offer they can start to offer a product. We normally see the progression as

  1. Service normally wrapped around or leveraging an internal technology that is the core of the contemplated product offering.
  2. System integration that combines one to three existing solution elements.
  3. Product that may benefit from related services and that often still interoperates with existing solutions based on what you learned from during phase 2.
Starting with a service goes by various names:
  • Mechanical Turk (replace software and hardware with people for maximum flexibility)
  • wrapping a thick protective blanket of consulting around your product so that no one is hurt by it
  • selling the holes not the drill
  • Wizard of Oz (pay no attention to the man behind the curtain).
  • Flintstoning (Fred Flinstone’s feet powered his “car”).
  • Manualating (a backward formation from automating)
  • the concierge method

Service First

By offering a service you can refine and adjust your offering with each customer, trying different approaches in parallel while engaged in ongoing discovery. Your ability to improvise enables you to continuously deliver “new features” and contemporaneous conversations allow for continuous discovery. Keys to success:

  • Continual improvements to your ability diagnose customer needs and constraints.
  • Refinement of explicit checklists for
    • engagement and new customer intake
    • internal processes that take “backstage” and in conjunction with core technology or specialized tools
    • quality of deliverables prior to presenting them to customers
    • post project assessment of impact on customer’s business, their perception of value delivered, and areas for improvement
  • An explicit after action review with the customer of the end to end experience and impact
  • The systematic substitution of software for labor as checklists stabilize and process steps are well defined to enable
    • lower cost
    • faster cycle time
    • reduced error rates

Add System Integration

In addition to adding software to your service process, embrace tools that the customer is already using and interoperate with them. This allows you to come to a clearer understanding of the strengths and gaps in the current workflow. There is no point in duplicating the functionality of existing tools the customer is already using, find ways to extend them to add value and increase your differentiate. The reality is that even when you get to the full product stage customers are going to evaluate your offering in parallel with other alternates and will often have a lengthy period of parallel operation as they transition from existing tools and workflows to yours. This system integration phase allows you to engage earlier and get a better handle on what’s going to be required to obsolete the status quo.

Typical offerings in the phase may include:

  • Templates or configurations that extend their existing system. Often this may take the form of Excel or Word templates, simple forms, simple survey tools, and visualization or analytic tools that “connect the dots” between islands of data in customer’s current infrastructure.
  • Simple add on tools that leverage API’s or established file formats supported by the customer’s current solution. If these can be bidirectional enabling interoperability the customer is more likely to invest effort in evaluating your offering because they can be confident their work won’t be lost with the data trapped in your system if they decide not to go forward.

Offer a Stand Alone Product

With phases one and two complete and customers willing to pay you for the value you have delivered you have a much deeper understanding of their needs and are much better prepared to offer them an upgrade path to a full product offering.  This product is likely to leverage all of the checklists that you developed in phase one and all of the lessons learned from sharing data and results with their existing solution.

The Key Benefit: You Can  Focus on Value Immediately

Normally you face one or both of the following key risks:

  • Desirability: will customers pay for our product?  To figure this out you need to
    1. Make bona fide offer at a given price. With a service you can do this as soon as you have a plan for offering the service and you can fine tune as you go.
    2. Negotiate an agreement with the customer
    3. Provide your offering–service, system integration, or product–and get paid.
  • Feasibility: can we make the product work in the customer’s environment? Service first reduces this to can we make the technology work well enough that it can make us somewhat more productive than a pure service offering. You can also iterate in the context of a service delivery model without having to remove the rough edges from the product–your customers will only see the results and if there are multiple failures you can fix them before giving the delivery of results.

Starting with as service allows you to focus on value immediately.  The transition to system integration still has a lower bar to entry than a full product in the customer’s hands and allows you to focus on differentiate value over the status quo.

“Without writing any code, the team learned what they needed. MVPs often don’t need code, but teams forget this. Our organizations are so used to solving every problem with software that we forget that we can learn what we need by faster, more effective means.”
Jared Spool “Avoiding the Wrong MVP Approach

Related Blog Posts

Photo Credit: Kevin Murphy, used with permission

1 thought on “A Common MVP Evolution: Service to System Integration to Product”

  1. Pingback: Design Your MVP In Two Weeks - SKMurphy, Inc.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top