Invest time in this and make it great. You will use them over and over again as marketing materials, and in meetings with partners, customers, investors and even with the press.

This should not be a flowchart, a set of wireframes, or even a concept animation. These screenshots should look like it is taken from the real site, so the viewer will know exactly what your site does. The screenshots need to contain most of the features of your site even before it is built. They should be explorable and understandable by anyone without a narrative. Annotations and descriptions are helpful but the screenshots in linear order should describe the business to someone that has neither seen nor heard of your business before.

Don't fret if it's not perfect, after all, you don't have a final brand that you need to stick to yet. You will edit these screenshots on an ongoing basis; however, this doesn't negate the fact that your screenshots must stand alone. This will help define your business and your value proposition to everyone. Just from looking at this, investors and customers should be able to give you concrete and valuable feedback that will help you build and refine your site or application.

When we interact with most products or apps, we tend to only interact with a very small portion of the product, but with an extremely high frequency. These most used and useful features can be regarded as the epicenter of the product.

Devote a larger amount of time, energy and money to this epicenter and then work on the supporting features to make your product minimally viable. Do not waste too much time on features such as login, account page or dashboards. Use it instead on the epicenter and make that part of the product exceptional.

The way to ensure that the epicenter is correct is to try as many productive variations on this epicenter as possible. It is worth making five variations of a composition, narrative, or structure with slightly different foci and angles, and test them with your friends and customers before investing in any of the designs.

How you choose to approach the epicenter will affect everything else around it. The epicenter is the largest furniture in the room—its style, size, weight and function will affect all the other furniture in the room. Don't waste your time and money on the small things until you get the big piece figured out—you live and die by the decision of what the epicenter is and how it works.

Once you have honed in on your idea and developed some concepts of what you want to build, create a minimum viable product (MVP). This is a small product that users can use to see if your hypothesis is working.

Prepare a list of all the things you want to get done in inverse priority order. This process gives you the chance to think through what is most important and most appealing. It enables you to reflect on the broad capabilities of this service and perhaps build and present these these capabilities in wireframes or prose form.

Talk to prospective customers to get as much feedback on your intuitions as possible before translating them into actionable steps for another person to build. Your development goal is to make an MVP. Thus, having a reasonably complete set of concepts or cohesive product will make it a lot easier.

You can now give the product back-log of to-do's to your technical co-founder or an out-sourced product development team to build your MVP.

If you can build the first version of the product without writing any lines of code by simply pointing and clicking, then...Congratulations! you have won the Grand Prize—you have built the minimum viable product (MVP) in no time! Any written line of code will deduct from the grand score of writing no lines at all because more code introduces more testing, more costs and more time expended. Worst of all, the more code you write for the first version, the harder it is to move away from this code since you have invested so much in it.

It is likely that the first version of your product or your supposedly minimum viable product (MVP) turns out to be not viable. Despite your best efforts, you might have picked the wrong epicenter or built the wrong product or chosen the wrong brand. So the less you invest in it the better.

The most effective way to limit the code written is to limit the time you give the programming team to deliver the first version. Engineers, especially the resourceful ones, can come up with creative solutions and fulfill your requirements within extreme time constraints.

After all, you might end up throwing this first version out, so don't fall in love with it.

Most people want to research and gather facts and figures to support the decision they are making in designing the first version. How big is the market? How likely are people to use a product like this? What are the preferred ways of communicating with customers in a target group? While these data points are sometimes useful, they could also lead you to a conclusion that moves you away from the epicenter of your product.

Before your first product exists, the data points you can collect are from other people's products. They are hypothetical offerings and vague generalizations. Without a real product that is collecting granular data about its actual usage, these indirect data points may cause more harm than good.

Instead, you should follow your intuition or hunch based on real conversations with real people, and design the first version of your product. You will get some parts right and some parts wrong. You will know which parts you got right or wrong by precise data about what users are doing with your product. These are direct data points that can confidently be used to tweak or change your product in the second version.

Sometimes if you have a successful launch of a first version, you may be tempted to trust your instincts when you build the second version of your product. It's okay to use your hunch on new feature additions, but it's better to rely on hard data for feature improvements.