Posts Tagged ‘product development’

5 Reasons to delay your product launch

Thursday, December 16th, 2010

We strongly believe in  release early and often. However when you work with other partners or customers, they may not think the same. So in a few years we have had experience with opposite ends and we have learned from it:  Although I still believe it is bad to delay your launch just to get more features in there, there are very good reasons that should stop you from launching your product.

1. You’re product is not clear. If you can’t summarize in a few sentences what users get out of your product and what action they need to take to get that, you might be in trouble.  If you can,  make sure that this message is also supported by your homepage. Not only the ‘what’ but maybe even more important:  the action users need to take.

2. You’re marketing is not in place. There is really no point in releasing a product without a plan on how to gain customers. If you are not able to start promoting your product, what’s the point? Nothing feels more disappointing than releasing a product and getting no feedback at all.

3. You can’t even use it. Aiming to release early does not mean delivering a barely working product. Attention for usability must be included in the most basic version.  So if you’ve got low quality instead of  less quality features go back to the drawing board.

4. It’s not that impressive. Expectations on design and usability have grown quickly over last few years. Users are no longer impressed by just a good look, you need to impress them with your product, but not just the product: the whole experience has to ooze the quality you deliver.

5. You did not review and test the code. Especially if you have outsourced development, I think you need to closely examine the quality of your product internals. If you can’t do it yourself, hire someone.  Even the best developers make mistakes and take shortcuts once in a while.  Even if you have tested everything, you are still going to find lots of bugs and flaws in the first weeks, so the more you find yourself, the sooner you will get real feedback.      If you believe you can rely on bugreports by users:  you can’t.

It all comes down to attention to detail. Some product make it because they are game changing ideas, others are just lucky. However most products only make it because there is someone that is obsessed by every single detail, even when running into unwilling designers, developers or marketeers.

5 Reasons To Release Early

Wednesday, December 15th, 2010

There has been a lot of writing about the need to release early and often already, but I feel after doing many projects, I need to write a few reasons down anyway.

1. You are building stuff nobody needs. No matter how nice a feature will be, without real users, you have no way to tell if you are spending your valuable time on something that will convince users to buy your service.

2. Nothing like real user data. Your software may work great in theory, there is nothing like real volumes of data to test it. Many things can grind to a halt if you start having serious amounts of data. ( Things like search with ‘%LIKE%’ or pages listing ALL entries of a table)

3. Nothing like real measurement data. You can ask potential users whatever you want,  there is nothing like properly measuring what they are doing and what they prefer. With real users you can use tools like  Analytics to confirm that users actually do what you need them to do.

4. Ranking in Google takes time. As soon as you’ve got something out there,  Google can start finding your site, you can start optimizing text and titles and build links. The sooner you get started, the better.

5. Enough chances on a first impression. If you are worrying about scaring your first users of, think about the vast number of internet users out there.  The changes of ruining a first impression with all your potential customers are slim. Just don’t start promoting the product till you feel confident about it. There are many ways to steer the first users, e.g. an invitation based beta program.

Why helpdesks will always suck

Saturday, November 20th, 2010

As a small business we don’t have the luxury of dedicated support staff. This means that for some products I am both the creator and support desk at the same time.  So,  in theory  contacting the support desk should give you access to all available knowledge and answer any question.         Unfortunately, that’s not the truth.  There are always cases that  I do not have an answer to.

  • Sometimes users want to know stuff we have never even considered (e.g. certain policies)
  • Or I will have to dive deep into code or configuration to find an answer
  • Other times I just don’t know (e.g. when a certain feature will be added)

If I can’t answer all questions about our product? How will support staff ever be able too?

Now imagine any company of reasonable scale.  Those will have separate support staff that is at best a user of their product. So the best thing they can do  is  answer problems that have been answered before. Which might not sound that bad, as similar questions keep being asked, as they have lots of customers. However, this is also what creates the dreaded queues and even more support staff, that is even further away from the product.

Now, recently I heard someone say that Google  does support right, so it must be possible.   Let me tell you,  Google does not do support right.  It is almost impossible to contact Google and get a timely response.  However, nobody knows about that, because almost nobody wants to contact Google.

This all leads up to a single conclusion: If you get the same question more than once, you’re doing it wrong.   You cannot fix the helpdesk, because a helpdesk is just repeating the same bandages over and over again. What businesses need to do is fix the product itself.      The only fix for a helpdesk is to render them useless.