Do Less, Do It Well, Get Paid

As we are homing in on the final features of Krowde, our new software platform, it occurred to me that doing one thing well as opposed to doing many things not so well makes more and more sense.  We need to do less!  We need to do that one thing we are doing quite well, and we need to prove our business model.  So this is the statement as to where we are at today.  It is not that clear still.

Krowde is a mobile platform for retail business to communicate with their customers.

Explaining Is The Challenge

That said, I have struggled with the most fundamental part of the start-up business process, which is explaining what we are building in one sentence.  That is a real problem.  It is enough of a problem that one of my mentors told me outright if you can’t explain what you got in one sentence then you probably have nothing and should consider quitting now!   While I do agree with him, I am also challenging myself to fix this problem.   And I know I can do it because I am a writer. I also ask mentors and friends to help me solve this problem. They just have to keep patient as I ask them to listen to me, while I ramble on about this stuff.

What Does This Have To Do With Do Less, Do It Well, Get Paid.

Well, what happens to guys like me is we get all excited by the technology.  We love this feature and that feature and this extension and that plugin thing.  Yes, there are a ton of cool things we could do with what we are doing!  Some of that is the endless possibilities of a web app.  But, the fact is that we need to reverse course, choose a micro niche market at first, reduce all our features to the bare minimum and then find out if customers are willing to pay for it.

How Does This Impact What We Do

So as we hammer down to the basic MVP (Minimum Viable Product), we are shedding features that can wait.  We are skipping systems and solutions that are not necessary now.  We are focused on just about getting to market and not all the things we could be doing. So the sentence about what we do; it do needs to be succinct and clear!  That is a challenge when we love to think about the possibilities of the future.  But the future is a long way off.

Get Cold To Tech

I just have one thing I want right now and that is both a working version and 10 customers testing it out.  Thinking is ok, but it all goes on the like to have list.

 

Dealing with Feature Overload in Web Product Management

Simplify, Simplify Again, and Simplify a 3rd time

Having come into contact with at least 20 different websites and start-ups over the past 2 months, plus having to manage all the features in our new start-up Krowde, I am starting to see the light on the words “Simplify, Simply Again, and Simply a 3rd time”.  Back when we were at Caffeine Spaces in Boca Raton, someone wrote this on the dry erase board.  It has a lot of meaning to me and can be applied to so many aspects of building out a website or mobile app from design, functionality, marketing, architecture and other aspects of these tech start ups.  I am focused on product management in this context.  (but I could write another article on any of those disciplines)

Feature Junkie

It has a lot of meaning to me because I am a feature junkie. Everytime I come up with a new product or concept, I can think of  a million cool features.  This is what we do as creative people and when you combine that with a technologist, more specifically a web developer, you can have a thousand little features that are cool and different and meant to change the world, even a world within a world.  But overall, what you are doing with complexity sometimes, is really showing off your ego.    We all want to show off what we can do, how smart we are, and we are, but not always in business.  Trust me, it’s my downfall.  In web product management too many features and quite often the wrong features can be the death of a product or at least delay it indefinitely before it goes live.

What’s The Delay And I Want It All Now!

Now, if you think about it, how can you produce all these features when your time is limited.  That is not the real question.  The real question is what features are really needed first, and what features can’t wait.  I can’t really expound on the features in Krowde that I am talking about, but I can come up with an imaginary app that I probably will never create.  Let’s call it Park Finder, and let’s say it was being built for iOS and Android.

Anyway,  you have spec’d out the mobile app.  You have come up with a dozen great features from a map with icons, a search of that map, a link to that park’s page, a listing and a small profile per park, the ability to share that Park with your friends instantly via Facebook, Linkedin, Twitter, an ability to talk about that park, an ability to upload pictures about that park for others to see, rate that park, a list of parks by ratings, park contact info, park office instant chat.  Wait a second!  Park office instant chat.  That needs to go into the list of “Would Like” stuff.  And that is the issue.  In fact, that list has a lot of cool stuff, but ultimately his park finder app could actually be live and working with just 3 features, a search, a map and a link to the website for that park.  All the other park finder features sound so good in your head and they are, but the customers don’t know what they don’t know.

Customers Don’t Know What They Don’t Know

I like saying this line and it has come back in many conversations, because it is really important and tied to the simplification concept.   The second issue with product complexity occurs in the mind of the technology founder.  Sometimes they think that more is better.  They think that the value increases with number and breadth of features.  But it is not exactly the same for the customer or customers.  Customers don’t always think the same or use the same features.  When only 5 out of 1000 users used that feature, then of course it was not very important.  Also, from a development standpoint, what about getting the thing finished and out to the market.  That is what is important.

Timing

Getting the Park app out into the market, with limited features is the best way to do it.  It is what Fried says in Rework, Brad Feld says in his blog and it makes common sense.  If you want to get your product out there and in the market, only include at first the core features, the features that make your product usable.  It will not fail because it does not have all the final pieces and bells and whistles you envision.  It may be that the park finder app may have been well received and done very well with only these basic features.  You have the time to add new features after that.  Add your sharing, commenting, rating and other features later on.  It is painful, but worth it and the difference in your app making or not making it to market.

What Can I Live Without?

In the end people are the problem, because even I have fallen into the “I want it all” trap.  And then I was the problem. You think you can have it all, but sometimes more doesn’t necessarily sell your product.  Sometimes less does.  Sometimes doing a small thing well is more critical than anything.  There are products and services that are bigger, feature rich, etc, but they are not for the small boot strapped start-up.  There is a cost associated with more, and sometimes those features never amount to anything or any usage.  The people you can’t always control, because they may be in charge and have the purse strings.  But at least you understand yourself what the issues are, and can say to yourself, what can I live without?