"Some problems can't be solved with minimum viable products"

Discussions
#1

@ian tweeted the other day about the limits of MVP:

Some probs can't be solved with minimum viable products. Wish we'd see more bootstrappers on problems like that. Even if it does take longer

— Ian Landsman (@ianlandsman) January 28, 2014

I sorta feel like I’m in the bucket with what I’m doing, both because of the choice of problem but especially because of the choice of market (enterprise).

Part of me does worry that I’m just giving myself excuses for not succeeded fast enough, dammit. I mean, I do know of companies that have sold in to enterprises with nothing more than a wireframe.

What do other people think about this? @ian, I’ve read my own situation in to your tweet - what did you actually have in mind?

1 Like
#2

I’m not sure from your landing page I fully understand the app, but it sounds like an email follow up automation thing. On the surface it doesn’t seem that tied to enterprise to me. In that space the things like Pardot and Hubspot are enterprise kinda solutions where they do that email automation but also track loads of other stuff, hook or are your CRM, etc.

We sell in the enterprise world a fair amount with HelpSpot. It depends a bit on your product but it’s not really that hard. We don’t get as many sales as we could probably since we don’t have a sales team and that kind of nurturing setup, but we’ve gotten this far without it. As we get bigger some more of that stuff may come in.

Perhaps if you post up some more details it’ll be more clear.

#3

I think I’m very much in this boat. My SaaS is physician scheduling for a niche within the healthcare market. I had not realized how convoluted a problem this was when I started. There are so many constraints that go into these schedules that you can’t simplify/minify without losing the advantage over doing schedules “old-school”.

Also, I didn’t know about the lean startup movement or any such thing when I was just starting (like, 2006).

Success is definitely slow in coming, but the good news is that it’s steady.

There are definitely bootstrappers out there who do this (I’ve met a few) but you don’t hear much about them because there is less reason to promote themselves.

I suspect most complex problems that are solvable by bootstrappers are of the intricate domain-specific variety, and that means that if you are not their core audience there is little reason for them to promote their product to you. At least that’s how I feel when I go to entrepreneur meetings in LA. Some dude will tell me about his latest photo-sharing app and get me to download it, and I tell them about my business and they say “umh, ok, sounds cool, I guess.”

2 Likes
#4

Haha. Yeah, that’s pretty much every normal person I’ve ever explained help desk software to and a good chunk of the bootstrappers also :slight_smile:

#5

D’oh! It would help if I had updated my profile with the right link… Trace Email Studio was something I experimented with for a few months, realised I didn’t have the passion to make it work, and returned to my roots… enterprise-grade communications management.

My product is Trace Communications Planning Studio. It’s for companies that send out millions of emails, letters, SMS, faxes, whatever per year and might have a few thousand flavours of communication (not counting one-offs). Currently, if you’re in that situation, you’d typically have no idea what you were actually saying to your customers. Ever spoken to (say) an insurance company and got conflicting messages depending on who you spoke to? I’m trying to solve one part of that problem - the part that has to do with written communications.

#6

That’s been my experience, too. Fun challenge trying to describe what I do to people who don’t spend all day up to their ears in it… another couple of years and I might’ve worked it out. A lot of the time (outside of tech meetups of course!) I stick to “I’m in IT” and try to move the conversation in another direction!

#7

If I am funding the development of something, then I want to be able to get v1.0 out in 6 months or less. If I can’t do that, it is just too risky for me.

I think most of the reasons people give for not releasing don’t actually hold much water. See:

1 Like
#8

I agree that most reasons for releasing don’t hold much water. And I also agree that having more than 6 months development on your own coin is risky, especially given that it’s likely to take (as you say) 18 months or more for a SaaS business to build up steam.

Part of why I’m interested in this conversation is I do wonder how valid my reasons for not releasing earlier are.

To be honest, the reason it’s taken so long is probably naivety and not knowing what I was getting into. In any case, the biggest part of the time spent has not been developing the software but rather understanding the problem, and working out how a solution would look.

#9

I’m very much in this same boat with my upcoming analytics app. I want to do advanced SaaS metrics analysis, but I need to get the business figures somehow first.

How I’m solving this problem is by starting with a smaller product (simpler analytics over Stripe). Here’s my explanation of how we cut the features: http://www.happybootstrapper.com/2013/cut-features-for-mvp/

In principle, I just dug deep enough to find something that’s valuable enough on it’s own (but is also a stepping stone to the direction where I want to take my product).

I believe that when you are bootstrapping, what @Andy said is essential. There’s a risk anyway and the longer you build without being in contact with real paying customers the more you risk going into wrong direction.

Of course, with this strategy I’ll have to fear if my minimum content is enough. That sucks too.

#10

It took we a while to “get” what folks like @patio11 have been saying around “Productized Services”.

I really think it is a good strategy overall and especially smart when you are trying to narrow in on a larger product/market. I wrote about it a bit more in issue #5 of BootStrapped Weekly.

#11

Absolutely agree. Wish I’d known about productised services two years ago. The consulting to productised consulting to product pathway seems like such a great idea in hindsight. As it is, it sure does change the way I look at things.

How long does it take to productise consulting, though, I wonder? For a rookie, I guess it would mean at least a couple of years working for someone else to build up some base-level skills, then another couple of years building up your consultancy, possibly a little longer to specialise and build up expertise, and then another couple of years to transition over to productised consulting. Hardly a quick road to riches. (Not a criticism, necessarily: it seems like a slow, steady, consistent road to riches.)

#12

FWIW: I know people who made the “day job” to “consulting” switch in literally a matter of weeks, and I know consultants/freelancers who had productized services available literally the day they decided to offer that as an option.

It’s not a “this requires years of toil to set up” kind of business. (SaaS generally strikes me like that, to be honest. I know of darn few SaaS businesses which pay the founders market wages at the first anniversary date. I’m virtually unaware of consultancies which don’t.)

#13

I think too many people make the mistake of thinking that an MVP is necessary for all products. It’s not, primarily because the purpose of an MVP is also misinterpreted. The purpose of an MVP is to prove a hypothesis valid or invalid with the least amount of work. If you know something, then by definition, you don’t have to prove it and therefore do not need an MVP.

But if your question is “Will people pay for X”, where X is a product that does A, B and C, then you have to consider what your MVP is to test that hypothesis. Let’s say it’s helpdesk software. It’s pretty clear that people pay for helpdesk software so the question isn’t can you get them to pay for it. It’s can you get them to pay you for it. This is a marketing question. NOT a development question. And in such a case, you don’t need to build the product. You need to build the marketing engine, or at least a semblance of one that helps figure out the answer to the question.

If you’re building an enterprise software package (like me), the question isn’t “can it be built”, “can I build it”, or even “will they pay for it” in most cases (especially if they’re already buying that type of product). It’s “can I get noticed by enterprise customers and appear legitimate in their eyes as a vendor”.

Make sure you’re asking the right question behind your MVP and it’s a solid scenario. If you’re not asking the right question, then an MVP proves nothing.

7 Likes
#14

Wow, thanks, this just makes so much sense!

Do you think it’s possible, though, to really test a marketing engine in the absence of a product to actually sell? At the very least, having a product has to be incredibly useful when it comes to marketing and selling a product, right?

#15

LaunchRock is designed explicitly around launching products that have either not been built or are not yet ready to launch. It’s entirely possible to build the marketing website for a product that doesn’t exist yet. I did it back in 2012 and sold $500 worth of monthly recurring subscriptions without even having a product over the course of 4-6 weeks and it was a super-crappy looking website.

The specifics of how you validate the “will people buy it” will vary from product to product, but it’s definitely possible to do this. By the specifics, I mean: do you let people try to pay for it, do you take their money, what do you tell them after they purchase, do you simply add them to a waiting list, etc.

On my end, I took money via PayPal and whenever an order came in, I refunded the money immediately and sent them a note indicating that it wasn’t ready yet. It worked well and over the last few years, I’ve made several thousand dollars above expenses from that product. But without knowing what the market looked like, I’d have been forced to build it first, commit a lot of resources, and potentially walk away completely empty handed.

Instead, I proved out the marketing to see if people were willing to pay for it. The answer was yes. So I built it, invested time and real money into good design and product development, knowing in advance that people were going to pay for it.

Totally possible. Is a finished product useful? I’m not sure that it is. What does it do for you really? It gives you something to deliver to the end user of course, but if they aren’t willing to pay, it’s irrelevant. Demos maybe? There’s tons of software that’s sold through a video that talks about the product without actually showing the product. Tell a story instead about how the software solves a specific problem. Tell what pain it solves. Then see if people are willing to pay for you to solve that pain.

If not, don’t build it.

1 Like
#16

So, first off, I totally agree that this is possible for certain products. You’ve clearly demonstrated that it is. I don’t agree that it will work for every product, though - at the very least, not equally well.

My product is very solidly enterprise. My experience to date is that it’s very difficult to sell without having the product in a pretty good state. The response to, “I will solve this problem you have in 12 months” is “Come back in 12 months and we’ll talk.”

To be clear, your advice is GREAT ADVICE that anyone starting out should definitely listen to. I just wonder if there are certain markets or problems that require a long hard slog before you can get that first credit card number (or purchase order.) And if there are, whether those problems are within the reach of bootstrappers.

#17

Clearly there are things that aren’t in reach of bootstrappers. New cancer fighting drugs, for instance, or anything else that requires millions of dollars in up-front investments.

I think there’s so much out there that is within reach of bootstrappers that it’s not worth worrying about though.

1 Like
#18

My point is: That’s not an MVP. The customer clearly has a problem they would pay for and you’re building a solution for it. What’s the question you’re trying to answer? Is it that the customer will pay for it? They very clearly would if you built the right thing. No MVP is necessary and it won’t work because the answer is already known.

Your problem is that it takes a long time to develop. There’s no MVP that will solve that issue because behind it, there’s not a question.

What you’re saying is that the customer has a set of requirements that need to be met and you don’t meet them. That’s not a suitable situation for building an MVP because there isn’t one. Either you meet their requirements or you don’t.

One of my other products that I’m working on is in a similar situation as yours. It’s called AuditShark. I first started talking about it on my podcast a few years ago and have referenced it on my blog even before that. It’s been in development for quite literally years. I catch a LOT of flak for how long it has taken because I talk publicly about it and people push me for building an MVP instead.

The problem is, they assume that they know the question when they don’t. To build an MVP, you need to start with a question, such as: “Will people pay for this?” If the answer is definitively Yes, then no MVP is necessary because the answer is known.

However if the question is: Will paid ads work for getting me in front of enterprise customers? Well that’s an entirely different question and is suitable for an MVP. Try out a bunch of stuff with as little effort as possible to try to prove your hypothesis right or wrong.

I’ve got a blog post I’m writing about this very issue because I think a lot of people misunderstand what an MVP really is. The sole purpose of an MVP is to prove an answer a question right or wrong. You have to have both the question, and a hypothesis about an answer to that question. Contrary to popular belief, an MVP has almost zero to do with actually building a product but the difference is so incredibly subtle that most people miss the connection, in part because there’s not a good baseline for the terminology and the word “product” is used to mean a lot of different things.

2 Likes
#19

@SingleFounder’s line of thinking hits home with my new SaaS offering I am building (Burst Search). In my case, I have spoken to several contacts that I have existing relationships with that are using a similar product. The response was mostly positive and they said they would consider my new offering. However, without a completed offering it is hard to convert these into actual future sales.

I’ve also tried Adwords as a marketing channel to drive traffic to the launch page. The results were abysmal - several hundred dollars and zero sign ups. This initially deflated my enthusiasm, but I’ve decided to re-double my efforts on both the product front and on trying to drive more launch list sign-ups.

Related to this discussion: Is it possible that some products are not as conducive to people signing up for a launch list?

As a technical founder, I think it is easy to get caught up on the product side and make excuses for why the launch list is not growing. If you know there is a market, and you know you can build something, the only missing piece (which is the biggest one) is can you get people to pay for your offering.

Launch list sign-ups are one metric to validate a likelihood that people will pay. In the absence of a large launch list, it may be an uphill battle, but given the market I am targeting I believe it may require a higher touch sales process. I’m interested to hear other’s thoughts here.

#20

If you found out something useful (e.g. that no-one will buy this product), then several hundred dollars is cheap!

On the other hand, a lot of people end up with poorly targeted traffic from adwords because they don’t really understand how adwords works.