September 13, 2013

Beta Version of Your Product

When you develop the Beta version of your product, after MVP and prototype are tested, and there are some insights about the product and market fit there are more things to consider.

This post primarily focuses on first versions of consumer applications and small to medium applications for businesses (i.e. without long sales cycles and complicated sales models), but it can be applied to other applications (the web or mobile) and even hardware products. Except you can’t iterate or add features easily if you have hardware product.

Many people confuse MVP and Beta version. MVP is just a test that there is a market for your idea, you don’t need a product to test it. Presentations and prototypes are enough. You need to communicate with your potential audience and engage them, describe the problem and show the potential solution.

Once you get to the stage when you want publicly release the first rough version of your product consider following items: primary market, initial feature set, and product experience. Pricing is not included here despite the fact that it’s important, and you can start charging people even for a beta version, but for pricing alone you need to take into the account many variables, and I’ll describe it in another topic if someone is interested.

Once you validate your idea and you know there is a market for it - either by collecting potential users contact details, or taking pre-payment for your product, you can start the development.

Consumer vs. Business product

For consumer products, you will need to spend more time on polishing the application. You will need to make it look sexy. If you have a limited budget - don’t bother about it too much. Making your app look perfect will cost you a lot. Think of a design for your product as a fixed cost that might be as much as half of your budget for the application itself.

It will take time to have few versions of the designs regarding general look and feel, and even more time to finish all small details. However, if you have time and money to do it - you won’t need to spend on it much in the future as you will have brand guidelines, and rest of the application can be build using just these docs.

For example, once brand guidelines are done, and you have the designs for few pages or screens, rest of the application can be build using these materials - when you want to add page, your developers can use these guidelines to style the additional pages.

The application you build isn’t the only one your users have - bear that in mind. Don’t invent new ways for users to interact with the information your application manages. At least in the beginning. Mainly because you will spend time arguing about it with your co-founders or teaching users how to use your new innovative way of interacting with your application. I know at least two startups who were doing it - co-founders spent way too much time arguing on this topic.

Plus, the way users get used to interacting with the application comes from the ones’ they use the most - whether it’s Gmail, Facebook, Tumblr, or other popular services. These mainstream applications will shape the way users interact with other apps - this is especially true for mobile. By using these mainstream applications, your users will expect or at least know how to use certain features, and it will help them to understand how to use your product, and make it easier to adapt to it.

Business applications have a different perspective - your users won’t care too much about how it looks as long it looks good enough, is usable, and most important if it’s solves business problem your customers have.

Focus more on convincing your customers that your solution works. Video interviews with your current customers, reviews, and demos work great. If you have a demo of your product ask customer details before they can use it - so you have a phone number to call in a day or two after they’ve used it. Even if they sign up for a trial, ask their phone number, so you can call them and ask about their initial experience.

When you do initial market research - try to use your competitor’s demos or if there is no competitors (which I doubt) spend more time on stakeholder interviews. Do 5-7 interviews, invite them for coffee and just talk about the problem you are trying to solve. From these interviews, you will find a lot about your customers business, especially if you are building a product in a niche where you don’t have enough personal experience. This will help to shape your application initial feature set and focus on the problem.

Initial feature set

Don’t build too much, but don’t build too little.

Facebook has added the feature to edit comments from mobile phones only this week. A long time after this feature was available on their web version.

Make a decision about your core features (as minimum as possible), and focus on them. It’s likely that your competitors have way more feature that you can build for your beta version, focus on core features and features around it, and do them well.

If you have direct competitors, it’s usually better to have some differentiator to their products. As a rule building a new platform because some product misses a small feature isn’t a great idea simply because your competitor can add it faster than you can get the critical mass of users.

However, you will probably need to build more features even after you cut core feature set for your application. These features will be wrapped around your core features, and they will make your application easier and more intuitive to use or make overall experience stand out from your competitors.

Product experience

What leads us to product experience. If you don’t add too many separate core features in the initial version, it’s you will still need to implement more of smaller features than you initially planned.

Think of email notifications, options to invite other users. User flow through the app - different depending on if the user used your application before or no. For new users, you want to make it as easy to use as possible, and encourage them to invite their friends, colleagues. Also, your app will need some admin panel, so you can manage content in case there is some inappropriate added to your platform. Email newsletters - add MailChimp integration. Metrics - add Mixpanel, KissMetrics, or Google Analytics.

These features won’t be necessary critical; your application will work even without them, but you will need to implement them if you want your clients to start using your application faster. For example, if you build the business app for teams and have an option for users to invite their team members, you can implement step by step guide for staring new project or just getting users going, so they can invite their colleagues and start working on a project faster.

Same goes for consumer applications if this product has some social aspect - either comments or suggestions for friends. Some peers in a social circle in the app will be one of the factors that will make your users come back to the app.

The points above are about product experience in the application itself. However, product experience will start a long time before users install the application or start using your product. Everything will matter in this sense - reviews they read on Twitter, HackerNews. The design of your landing page. Description of your application in AppStore or Play Store. This is just a fraction of what will make your users pay money for your product. Make sure whatever experience they have - they like it, and once they bought it makes them feel good about the decision they made.