April 16, 2019

How do you pivot a product when you already have users?

I have a product that is being used actively by a small set of users. About 25% of them use it as I intended, the other 75% use it for a tangential purpose. The way I see it, I have two options:

  1. Add more features for that 75%, which would end up muddling who the target audience is for the app.

  2. Make a second offering from scratch that is targeted directly toward them which would end up splitting my focus between two apps.

Are there any better ways to handle this? I'm hesitant to disturb the 25% using the app as intended because one is a large enterprise client.

#ask-ih

  1. 5

    We (4 geeks) had a product that we'd been developing and supporting for 3 years, with $500k of seed money. Peak annual revenue was about $250k. This was enterprise software.

    We took a venture round of $5m, and part of that deal was that we get a business-focused CEO. At the time, we were kinda happy to do that because none of us felt like we were good at those tasks.

    We had a situation not unlike yours: our product had a specific technical niche, but most of our adoption was from a business area that didn't fit the technology directly, but rather just relied on the tech being faster and cheaper than many of the alternatives (like you, we had like 75% tangential usage).

    We decided to focus 100% on the majority business niche, pivoted the development to something that was more directly related to what they were doing, and shut down the original product.

    We gave the current users 12 months of support and bug fixes, stopped all feature development, and in one case the customer exercised their source escrow rights to continue using the product for 3 or 4 years, with very minimal support from us.

    But ... it took years to recover the momentum that we'd previously had (both from a development point of view, and revenue), and ultimately the company went under.

    If I had a chance to do it again, I'd be very much more inclined to maintain the original niche (perhaps with reduced effort) and build out the new niche concurrently.

    What's your long-term view? If you split the product, do both of them have independent potential? Can you see yourself enjoying doing either of them? If you're less committed to one or the other, then that might help you decide.

    My instinct would be to think about branding the 75% product separately to try to avoid the "muddling" effect. Since you have a common base now, maybe start that out with an "extension pack" or something, which lets you establish the second product, and move towards separating the products.

    I think the "problem" of split focus is often over-exaggerated. If you can sustain a side-product (and many people can/do), then you can sustain two products.

    If you feel like you cannot sustain both apps long term, perhaps you could attract a partner to take on one of them? Or even sell one of the apps?

    Good luck!

    1. 1

      what is "source escrow rights" ? is this something common in enterprise software contracts?

      1. 1

        Yes, it's quite common, especially for smaller software vendors.

        Enterprise software tends to be tightly integrated with the rest of a company's system, and so changing it out is expensive and time-consuming.

        So ... if the software vendor goes bust or discontinues the product, a source escrow agreement means that the customer has a legal right to the product's source code (for their own use only, etc).

        Iron Mountain is one of the major escrow agents in the US. The way it works is: every time the software vendor does a new release, they send a copy of the source to the escrow agent. The agent then follows the instructions to build and test the product. If it doesn't work, they bounce it back to the vendor. Once it has worked, they inform the client that a new release has been escrowed (and they're then free to start to use it knowing they've got that backstop).

        It's not a great outcome for the customer, but at least they've got the ability to pay someone to fix bugs or migrate to a new OS, or whatever else they need to do. They can then migrate at their own pace, or continue to maintain their private fork of the old product indefinitely.

    2. 1

      What's "muddling effect"?

      1. 1

        OP said, "... end up muddling who the target audience is for the app". Which I think is a real thing, especially in the early stages when company and product are often indistinguishable in customers' minds.

        To avoid that confusion, if the OP wanted to continue with both products, it might be worthwhile trying to separate them to avoid muddling the marketing messages.

    3. 1

      Thanks for the reply. Definitely gives me some perspective. Going to make another app and see how it goes.

    4. 1

      Interesting story. have similar thoughts from various ventures. niches are often big enough

      As for OP 2. is probably less risky.

  2. 1

    Is anyone paying or are these free users?

    1. 1

      All paying users.

  3. 1

    Here's a good article on the topic https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22. It talks a little bit more on whether rewriting applications from scratch is a good idea and also includes a few good examples such as with basecamp that are similar to your case.

    As David suggested, it might make sense to look at creating a second offering that's specific to the other 75% of the users while letting the users that are using the existing software as intended ride it out, especially if your livelihood depends on it. If you can afford to potentially lose the 25% users including the enterprise client then pick the one with the least amount of work, eg just pivot the existing product.