Spikelab

The Plusconf event on web applications and lean startups had a great speakers list: Hiten Shah of Kissmetrics fame, Allan Branch from LessEverything.com, Todd Garland CEO of BuySellAds.com, Dan Martell c-founder of Flowtown, Noah from appsumo and David Cancel CEO of Performable. Being able to tap into such great amount of knowledge was an absolute pleasure and a great opportunity. With such a group of great entrepreneurs the conference was the success everybody expected (minus some technical difficulties…the joys of technology). The event has been recorded so if you want the full thing you can download the video on the livestream website. Without getting into the minutes I wanted to share the top things that were useful to me and might be useful to you too.

• Talk to people like if they were your friends. This seems a given, but if you’re finding it harder than you thought, especially through electronic mediums, you are not alone. It’s not uncommon to feel cheesy or sounding like a marketing droid with canned texts, but give yourself some time and consistency and you will work the magic out.
• Avoid requiring registration if possible and limit the number of mandatory fields. This is an interesting one. As a user I bet you regularly annoyed by the amount of info you’re required to enter just to take a look at something. But when you’re on the other side information about your users is more precious than gold. At the moment I’m building a survey to use during Customer Discovery and struggling to keep the number of personal questions down. The main problem is that without a clear understanding of who you’re talking to whatever feedback you get is easily to misinterpret.

• Never promise a feature, tell ‘em but no promise. I’ve experienced first hand the anger of users who felt features had been promised and not delivered when the company had never done such thing. On the other hand being able to share your planned features seems to be a good opportunity to gain traction and encourage retention, but I’ve no data to back this claim up.
• If you’re not embarrassed of your application, you’ve launched it too late! If you are a bit of a perfectionist, and most engineers are, you are prone to delays, trying to iron out the last bug and work out on the last todo on your list, but the truth is that Todd is right. In a recent interview to Hiten Shah Andrew Warner asked a similar question about MVPs and how they could damage someone’s credibility by getting under the customer’s eyes too early. Hiten asserted that it shouldn’t be a problem for an entrepreneur and simply take any such outcome as a sign that the person you’re talking to is not an early adopter. And this is the crucial concept: early adopters are those that you should seek when launching early because they are the ones ready to get past the ugly looks and the rough edges and the ones that believe in what you are doing. There is a great value in being able to put things out there quickly, you reduce the risk of producing something people don’t want and you’re more likely to figure out what works fast. There are also risks of course, but it seems they can be managed by good communication and talking to the right people.

• If you are desperate for cash VCs will smell that and you’re worse off than if you raised money early. This was something that came up as part of David’s reply to a question I had with regard to the timing to seek investors. I’ve had some interest for my startup, but it seemed too early and I didn’t want to give away shares like that, at least not just right now. This certainly has had a strong impact on my ability to grow the business and I’ve been wondering if I should have done otherwise. I guess David thinks so, which I cannot really disagree with, maybe it’s just a problem of finding good investors as he suggested.
• Careful with your obsession, it’s probably not what your market wants. Have you ever been so excited and about an idea that you wanted to see it live right now and fell into an hacking frenzy? In the beginning I’ve hated doing customer development, it felt a lot like lots of talking and no action, it’s hard to measure progress with that when you’re used to build code and systems. If necessary you should remind yourself daily that the stuff you envision and the cool things you could put together are not necessarily what the market wants and therefore something you can build a business on. Of course this does not mean that you should change your ideas based on a market’s whim, but you should certainly make sure the market wants what you want to build before building it.

• Problem team <-> Solution team. If you are in a startup or have engaged with Agile and the new Devops movement you are aware of the importance and challenges of cross-functional teams and working together to avoid the silos problem. Hiten mentioned that at Kissmetrics they have only two teams: the Problem team and the Solution team. The former focuses on identifying and validating a problem while the latter finds a solution to it. You can see the power of that and there is certainly beauty in its simplicity, although scaling it to larger scenarios would probably be challenging.
• Put Kissinsight on your pricing page and you will be surprised. This was actually a comment by someone in the audience. Kissinsight is another product that Hiten is working on that provides you with a quick and easy way to collect feedback from users by popping up a little unintrusive dialog box as you browse. The person that commented said that Kissinsight was incredibly helpful to adjust their pricing scheme which in turn increased their sales. If you have ever looked at a pricing page and decided that none of them was quite what you wanted/needed and walked away you have just made a case for it. I know I have.

• Their interest first. Talking of spreading the word and gaining visibility for your product, social medias are a must, bloggers at the top. Have you ever talked to a stranger about something you thought was awesome and being disappointed because they weren’t as interested as you expected? Of course it might be that the topic was of no interest to them, but chances are the problem was actually with the way you conveyed the message and what you attached to it. What I found very useful in Noah’s talk was the reminder that when you contact a blogger or talk to your users you have to put their interest first and this has to be reflected in all your actions, especially your communication.
• It’s not about a need, it’s about a relationship, contact bloggers before your launch. This was a handy tip. Do not wait to have a demo ready before you contact bloggers, build a relationship with them over time. The easiest way it to be active on their website and contribute with high quality comments and material. Remember the previous point, do their interest, not yours, help them be successful and there’s a good chance you’ll get that help back when you need it.

• What were you doing first? what are you gonna do after? An interesting observation about user testing and context: when you run tests, even a survey, context is extremely important. All our actions are influenced by our current state so getting an insight of what that is will be very helpful to decode the answers. This goes hand in hand with the point about lengthy registration forms - striking a good balance is hard and very much product specific.
• It’s no more a mvp when you start scaling it. As an engineer without any prior schooling or experience in business or startups concepts like MVP (minimum viable product) were completely alien to me. After some reading and hanging around places like the lean startup mailing list a MVP can be defined as the minimum amount of work that can be done to learn something about your hypothesis. As many say, this can even be a bunch of slides. But then you wonder, what’s the minimum amount of work? What if in my case I have to code something up for maybe a week? Is that no longer a MVP? I asked this question to Dan and according to him a MVP ceases to be a MVP when you begin to scale it, ie users are buying and you need to meet a growing demand. By proxy this seems to suggest that there could be many different MVPs at different stages of your learning cycle requiring different amount of effort.