Perhaps we should be shooting for generality in the implementation - i.e. a well factored, flexible code base that models the ___domain well and supports a high level of reuse (and is written in Haskell :-D). Coupled with specificity in the solution - i.e. solves the problem perfectly for a narrow niche of people/organizations.
If you want to support many, or wider niches you re-use parts of your well factored code and produce separate solutions for each smaller sub-niche.
People spend money to solve problems. If the problem you solve is not clearly defined, you cannot define your customers and cannot target your marketing.
The validation you need might be "that's cool!" The validation your company needs is "that solves my problem."
Very true, and you're right that these are totally different forms of validation. It's a steep learning curve (for me), but I figured this particular blind spot may be encountered by some (definitely not all) other tech folks on this path.
I reached out to my ideal customer and told them I have an idea to solve a problem of theirs. They said they would love to use something like that, and they're helping me build my MVP.
Without reaching out to my customer first, my MVP wouldn't have solved their needs as effectively -- and there would have been too many holes in critical use cases.
After watching all the Steve Blank videos on Youtube, I'm a believer in "get out of the building and talk to customers".
I began like this, with some market research amongst potential users that I know directly. Worked closely with a few. But my problem was that I let myself lose track of this and, when I came back to them with my MVP, it had deviated (by virtue of me generalising it too much) from what they actually wanted to use.
So you're spot-on, and sticking with a few customers whilst building the MVP is probably a hugely important step.
> People don’t want a general-purpose framework for logging and visualising their progress towards personal goals. They want an app that tells them not to eat the donut, that they lost 2lbs this week, or that they just achieved their personal best running time.
Actually, they don't want an app at all. They want to just be skinnier so that they look more attractive to their significant other or potential mate.
> Likewise, they don’t want an app for general-purpose list-based collaboration. They want an app for smoothly collaborating in precisely the ways that collaboration works best in their organisation, whether that is list-based, project-based, chat-like discussions, whatever.
They don't want that either. They just want their boss to stop bugging them so they can feel autonomous at work and have their work mean something. And they want their work to go as fast as possible so they can go home to their kids and be good parents.
------
The biggest lesson that I've learned building products is that people don't want these products at all. But sometimes they find a product that they hope will help them become better at the things they actually do want.
People don't want to buy a camera. They want to be better photographers. So help them become better at what they actually want to do, and you'll find yourself selling more cameras.
That's something I try my hardest to stick to with Draft (http://draftin.com) and it's been working really well. I realize my users don't want yet more writing and collaboration software. But they do want to be better writers. They want more people reading their blog, or they finally want to tell their friends they finally published a book. So I constantly try to find ways for the app to help them get better. And not just the app, but I'll even have webinars, blog, teach my methods at writing, storytelling, getting more readers, etc. and now I have people paying attention to the things I make and sell.
---------
For these apps of yours, they look like really great places to start from. I think you could do a lot on their homepages and on your blog helping people get better at what they actually want to do with these things, and you'll probably find they are paying more attention.
I'm happy to help brainstorm some more on this if it would help. Hit me up on Twitter (@natekontny) or email (nate.kontny gmail).
I think it's safe to say the average app user actually uses a dozen of their apps on a weekly basis. In order for any app to break into a homescreen, it must add a lot of value/satisfaction to the user's life. Adding to what Nate was saying, a person wants to be a better writer or in better shape or more productive etc. There is already a problem of information overload, app overload is getting there too for many people. The only way to stand out in a crowded marketplace is to solve the problem in the simplest and most enjoyable way.
I like to ask myself: Is what I am making adding to quality of life? Making life simpler? Creating positive results?
Fantastic point, thank-you! Yes, totally agree. I think we, as developers, often forget this. I think it's definitely about addressing things that people want to do / be.
I may just have to write this above my monitor for the next few weeks, to correct my focus!
Absolutely. But I think there might even be a little more nuance to this. The classic quote is "people don't want drills, they want holes" that's why they buy drills.
But I think you could get a lot more out of asking why they want the hole to begin with. Are they trying to build a house to help raise their family better, or to become a better investor. Or are they trying to become better at being a contractor, which is the business they run? When you ask Why a few more times about the problem they think they have, you come up with all sorts of useful things you can help them with.
I call this the "Men's Soap Principle". Men's soap is no different than regular soap, but the fact that brands call it Men's, make's it applicable - and therefore men buy it.
Note however that this doesn't apply to everything. For example, Men's Multivitamins have different amounts of vitamins and minerals in them and there are legitimate reasons for the differences.
Same thing with women's shampoos. While there isn't anything that prevents men from using them, they are usually optimized for the types of products (esp. coloring) women typically use in their hair.
Interesting article. I'm sort of here now with something I'm working on, its incredibly general, and thats how I want it.
What I'm going to do however is pitch to the specific groups, the specific uses. I'm going to get out and talk the moms and pops crowd, the artsy crowd, the cyclist crowd and show them how/why they should be using it.
Maybe I've read it wrong, but it doesn't seem like a product/market fit problem to me, it seems like a "I haven't showed these people sufficiently how/why to use it for what matters to them" problem.
Edit: Rereading what I've wrote back I feel even more certain of something: perhaps the problem with creating a product that is too generic is that the gap has to be filled with education, if it isn't obvious on how to use it - like the case might be with a product that is very specific - then you have to fill that with a non-codey layer over the top.
Double edit: I think its funny how I see people write about "coder mindset" as a reason that they've hit a snag but yet still manage to stick to a coder-solution mindset. Maybe try a new layer of packaging, some education. Literally detach from being a programmer. Source: Programmer, marketeer, photoshopper background
That's what I was thinking. The ubiquilist product looks really neat, but there isn't a single use case on the site.
I wouldn't change the product (yet), I would find great use cases and present those in detail and with flair on the site, and then I would find ways to put that use case in front of more people who are like the ones in the use cases.
Possible use cases: show how a family with a dog that needs treatment gets organized to take care of their pet thanks to your product. How a mom & pop shop get their orders right by using the estimate feature as they work on them. And on and on...
Again, for my 2c, this is a marketing problem plain and simple. Close the IDE.
lol - Thanks absolutely, spot-on!
I'm not ditching UbiquiList, but I plan to expose those few simple use cases more elegantly. I believe I can track back from this general solution, with marketing / education, and encourage folks to come on in.
I agree that education is key. Also language / wording and what they see on a landing page to pull them down a path to actual use. I see this is MY problem, but I'm generalising about whether other tech folks also encounter(ed) it. I expect to get beyond it, either with this product or the next :-)
To clarify, I modified the title of the post slightly. Now "This Tech Founder's Blind Spot", as I'm writing primarily about MY blind spot, theorising other tech founders might have (or have had) the same. I definitely know some who never struggled with this, and I quite expect to learn and progress beyond this.
Great comments, folks and good to hear everyone's experiences, both similar and conflicting.
I don't think that problem is that your product is too specific. But it's targeted at a market that is used to getting things for free. I guess the market for $49 linux commandline tools is very small in general.
I would be curious to lean more about your marketing efforts and pricing experiments. Typically marketing/the business side is 95%+ of the problem for developers who do not already have a market of their own to sell to.
I have noticed that niche virtualization utilities tend to disappear quickly as they are aquired by the handful of large companies in the space.
I'd like to add a bit of a corollary -- people tend to like products that fit immediate and specific needs because they reduce the effort, mental or otherwise, associated with coming to grips with the product (you may have been going here anyways with your comment about friction).
We use things for a lot of different reasons, ranging from "my boss told me to" to "I saw it on TV" to "it can help me track my running better." All of these reasons get someone over their initial reluctance and get them to try something. Having a specific product (I can track my running) offers a quicker path to get over this reluctance than a more generic pitch (we have a system that tracks anything! If you spend some effort on it, it can even track your running).
Totally agree - It's definitely a question of overcoming reluctance. Sometimes, people can describe why they like a product but they just don't translate that into actual use. They probably aren't aware of their own reluctance, so we perhaps have to help them through it with those specifics, and then reveal the general use beyond.
Great post Ian! I can certainly relate on the lack of marketing experience but, I can't say that I agree 100% with your verdict that the success of a product rests solely on how specific a problem it solves. Depending on your product's niche, you might find yourself struggling with marketing a product because your potential paying customers are used to general purpose apps that solve most of their pain points, even if not all. Just because those general purpose apps, as you've put it, create such little friction.
For example, I'm working on a startup that caters specifically to runners. That's it. We analyze run data and create nifty little visualizations. The upsell is even cooler forms of analysis that someone like a track coach, amateur, or competitive athlete might use. It solves a very specific problem: "how can I tell that I'm improving as a runner?" and it has very specific answers like "you shaved 25 minutes off your 5K time based on your best runs over the last 90 days" or "in the last 30 days, you've spent 65% of your training at a pace faster than 7:30min/mi (your tempo pace) - you're in danger of overtraining or, worse, getting injured!" Although, I can't even begin to tell you how many people have told us to generalize our app. Include cycling, swimming, hiking. Maybe somehow tie it to nutrition or weight loss. Maybe also vie for the role of becoming the Facebook of fitness. And, of course, the number of times that we chose to turn down the temptation to diversify... I'm all for staying focused. Running is the first and last thing I think of each day, but I think it's also safe to say that being specific can sometimes equate to being esoteric and, that, can sometimes be a long and difficult road to follow. I'm not saying it's not worth it. I'm pretty happy. Although, it doesn't grease the wheels for success indefinitely.
Thanks, that's useful to hear! Agreed, I'm highlighting one potential "problem", but it's probably more complex and multidimensional than that: my aspirations for a general product, marketing experience, educating users about specific use cases.
Great to hear that you're gaining traction with runners and that you're resisting generalising your app. It must be tough, once you gain users, to decide on a roadmap.
Geoffrey Moore covers this in Crossing the Chasm [1]. He basically suggests that you have to specialize in an industry vertical to get beyond the early adopters and into the masses. Once you cross enough verticals, then you can come back and be a more general product.
I've also heard YAGNI [2] shouted at generalizations. People can spend too much time generalizing problems for broader application that never comes. I don't know the right answer here, as it seems hard to measure how likely it will be that any generalization will be reused later. Perhaps it's ultimately judgment.
"He basically suggests that you have to specialize in an industry vertical to get beyond the early adopters and into the masses"
I think that pretty-much sums it up!
You make a good point that I've seen echoed in different ways in different books/articles/talks.
If I can chime in with my take, and I think you had something to this tune in your post, it's important to not only be specific but to be opinionated. You not only have a problem that you've targeted specifically, but you also have the a specific solution.
It reminds me of when I had to write papers in college and the professor would say "Don't just summarize the different sides of the argument, choose one and argue it. I don't care if you're wrong just argue it." I think startups are similar. You pick a side and you come up with a market strategy/argument for it. If you fail, you pivot. But at each step of the way you should have an opinion, an obvious solution that can be conveyed to the user (or investors).
Absolutely, I think you have to be bullish with whatever solution you first present to a potential market. That belief and (apparent) momentum are, in my opinion, part of what leads people to look harder at your offering.
Nice article, some ideas reminded me of a passage I read on Chris Dixon's blog a while ago.
"The successful products took big meals and converted them to snacks. The Internet likes snacks – simple, focused products that capture an atomic behavior and become compounded only by linking in and out to other services. This has become even more so with the shift to mobile."-
His entire post wasn't necessarily about 'specificity', but I really liked his 'snack' analogy. Looking at currently successful products, many are incredibly focused and snack-like.
1. A defined use-case (flavor) they users easily distinguish from other products.
2. Efficient interaction (consumption) that addresses the problem: quickly, simply, and mobile(ly).
Interesting take that this is down to software developer sensibilities. My initial thought was that it was due to shooting for as big a market as possible in the hopes that it would increase chances of success and non tech people would fall just as easily into the 'trap'.
This crossed my mind as well -- you start with a specific problem to solve, you dig into building a solution... and realize that whoa, with only a few tweaks this could be useful for this whole range of related problems...
But the compromises add up one after another, and by the time the general solution is built (with an immense theoretical target market), it's lost its heart. The people with the original problem won't be interested any more (because it doesn't speak to them anymore).
It's related to the problem of implementing every feature and permutation that users request ("no problem; we'll add an option for that in the settings!"), until the elegant solution becomes an unusable monster.
It's hard to say "no" to an addition that clearly adds value, but if you're aiming for a sharply-defined target, you've got 1 degree of "yes" and 364 degrees of "no".
Valid point, and I definitely see biting off more than I can chew as part of the problem. But I suspect architecting (in a lean way) for that bigger market, whilst hitting a smaller niche, may be the balance to be struck.
If you want to support many, or wider niches you re-use parts of your well factored code and produce separate solutions for each smaller sub-niche.