I often read that when it comes to startups launching a product the best method is to get a product out fast and optimize later. But what are the things you need to have nailed out of the gate?

The number on thing to get nailed down is the problem you are trying to solve. And its best if it is your own problem, but it could be a problem you are passionate about. http://techcrunch.com/2015/01/29/the-startup-advice-you-dont-hear-inside-the-echo-chamber/#.x08egd:hGbV Once you own the problem, wouldn't it be great if the market pulls the product out of you? That's how it should work as Marc Andreeseen states, to achieve product/market fit. http://web.archive.org/web/20070701074943/http://blog.pmarca.com/2007/06/the-pmarca-gu-2.html You can always feel when product/market fit happens. Now the big question is how to get to that elusive fit? One school of thought is to launch products quickly and use them to learn from the market. The linchpin concept is validated learning. But this is not the only school of thought on the subject matter! Pinterest founder, Ben Silbermann is a case in point. When they started, four months after launch they had 200 users. And people were telling them to admit failure and pivot. How did Ben know to keep going? I believe the answer is growth. They were growing 50% every month. and as Paul Graham writes, startup is growth. http://www.paulgraham.com/growth.html Lots of founders think of a product launch as a one time party and success depends on how many people show up. Its more useful to think of the journey, and not the destination. A drawn up clickable prototype on http://invisionapp.com  can be a step on the journey that is shared with a handful of users drawn from http://usertesting.com  to validate some assumptions. A landing page on http://unbounce.com combined with an email newsletter from http://mailchimp.com can grow your audience.  Get customers by offering a real value and asking them to pay http://stripe.com . Measure your growth using http://mixpanel.com. At http://Clevertech.biz we work with ambitious entrepreneurs that want to move quickly and build real products that create value. Most recently a client with who we worked with when they first started as four guys with an idea and continued enhancing a product for seven years, finally had their overnight success and sold for nine figures. There are so many ways to get there. What is your path? Only you can decide. There is much to learn and the journey is the destination.

MVP products may be incomplete, but they’re not low-quality.  Arena CTO Eric Larking recommends for considerations to keep in mind while implementing an MVP approach: 1. Effective MVP products demonstrate purpose and provide value—even in their most limited form. A group of users should be able to come back to  use an MVP again and again even though they think it could be better. This early adoption and feedback is what allows you to iterate based on what customers are doing. 2. MVP products may be incomplete, but they’re not low-quality. Remember—that first set of customers forms the market’s impression, so make sure they have a positive experience, even if you leave them wanting more. MVP isn’t a good fit for companies whose products can’t support in-place upgrades. If early adopters are forever stuck with the MVP while future customers benefit from updates, loyalty and adoption for future products will quickly decrease. 3. A MVP strategy is only possible when you are able to iterate quickly based on user feedback, and when you are confident in your ability to work quickly yet maintain a consistent level of quality. If you release the first version, and find out that customers hate a feature, or that another feature doesn’t work, you need to be able and willing to listen to those concerns, and make changes in a timely manner. 4. In a successful MVP strategy, the cost customers incur for updates and improvements must be low. In Arena’s case, we are able to push updates to customers quickly and transparently with minimal customer interference since we aren’t an on-premise solution. Read more at http://blog.arenasolutions.com/mvp%C3%A2%C2%80%C2%94minimum-viable-product/

1 thing - Product/Market fit. You can make it look amazing, but if you make someone no one wants you've wasted your time. How to do this - 1. Learn as much as you can about what your market wants before writing a single line of code. - Create a hypothesis. For example: "People will pay $10 for monthly box of makeup samples delivered to their door." - Test your hypothesis manually. For example: Create a landing page and buy some google adwords and see how many signups you get. Or, create a survey and ask questions. Or, call 100 people and ask questions, Or, create the box of makeup samples and sell it in person to 100 people you know and see if they pay $10. 2. Build an MVP. This is a Minimum Viable Product. It'll be tempting to blow your entire tech budget and throw everything and the kitchen sink in here. Don't do it. To learn how to build an MVP, read this http://www.stridenyc.com/blog/2015/1/6/when-and-how-to-build-an-mvp

Things you must have: Easy to understand what it is Compelling reason to use it Things you must not do: Breach user trust (privacy etc) Lose user data Embarrass user (eg post to Facebook) Make user feel stupid Make user feel like he is wasting his time (terrible performance, poorly designed forms, low uptime, etc)

It depends on what market you are in. In some markets, it isn't even necessary to build the product at all, just make the web site advertising the product beta. if no one signs up, you have a clue it would be a waste of time to even start building the product. However, if you are writing software for an intercontinental missile system, I am reasonably confident you will need more features than an imaginary beta provides. Ask yourself what will happen if we release and the users HATE it? Will the company be finished? If your bad software release is going to cause the missile to land in downtown Manhattan, a bad release is going to have some pretty serious consequences. On the other hand, if you are writing software for the general consumer and 100 beta testers hate the early release, you may have reduced your market by 100 but since you have another 6 billion potential users you can live with that. Do the absolute minimum that people will accept in your market. That will vary by market. Let me give you a real world example. We were developing a product to be sold to architects. Architecture is a form of visual art and architects are often trained as artists and are paid to think like them. Not surprisingly, they are highly attuned to how things look and how the look makes them feel. To them, if the color of the window border clashes with the color of the bold font, the software is horrible and completely unusable. This came as quite a shock to a non-visual thinker like me who thinks of colors as window dressing on functionality. But if you are going to sell to artists, don't be surprised if they apply an artist's eye to your software. Knowing something about your user will give you indications about which aspects of the software need to be well-developed before you release. Three things I would suggest: Do not release software that could corrupt valuable user data with no chance for recovery. Do not release software that encourages users to enter sensitive information without adequate protection against theft If you are the product manager, do not release software if you have not actually used the version that will be released yourself.

What matters most is identifying the one feature that solves the biggest problem you are trying to solve. Though UX and design are important, it is as not important as identifying a problem you are trying to solve. In many cases, almost all the product hypothesis are wrong. They will pivot at some point. There's not a single startup that I can think of that didn't pivot. Security, technology, etc are important as well, but you can always focus on these later when you have raised money and have the budget to spend in these areas. Would be happy to help out if you want to share more info.

It must be useful. It must have one feature that works well that no one else has. It should not have any issues that prevent the value from being delivered. It can even be considered beneficial to have a minimalist feature set. It keeps the focus on what is unique and useful. Pricing is completely unnecessary up front when you are trying to prove its utility. UX design should be complete but not final. UI design is a bonus and can affect how you are perceived, but is not critical if you have that one unique feature.

Well ideally you can just have a landing page before all this to validate your idea before you start building it and worrying about these problems. Build a landing page with all the features / UX design (mockup) that you can dream of. If people are signing up it's a sign that you should start building it. You can also figure out what features to build by doing this - Start with all the features you want and slowly take them out on the website 1 by 1 until you get 0 people registered. That will show you the features you got to have for your MVP. http://andrewgaleis.com/?p=18

I also believe that you need to be upfront about pricing. Even if you don't implement billing it should be obvious to users if you are eventually going to charge them. Not only does not doing so risk a backlash later... but giving something away is not the same as proving people are willing to pay for it.