Start broad, then go deep

The currently accepted wisdom is to start with “horizontal” prototypes, followed by “verticals”.

Horizontal prototypes

Horizontals are simple mockup simulations used during the project scoping phase. They are primarily used to get an overview from the user’s perspective.

Horizontals give a broad view of the entire system, so you can concentrate on the big picture, rather than getting bound up in the details. They are best used for understanding relationships across the whole system, for demonstrating the scope, and ensuring all behaviours are covered. It is possible to develop one entire layer of the design without having to consider the “how” of the technical implementation. Issues of consistency can be noticed and addressed (similar interactions are grouped by actions or location).

A horizontal user interface prototype allows you to gather more information from customers and designers. It also allows you to confirm business requirements, define/clarify the scope of the project, and get buy-in from the key stakeholders.

Horizontals can sometimes be presented in sales demos, to get exposure in the media, or to make advance sales.

The process of building a horizontal prototype can enable good preliminary time and cost estimates, but may increase the influence of the planning fallacy.

All essential user interactions are covered, every screen and menu and function is shown in some form. Most importantly, none of the features are fully functional.
No real work can be done.

Some level of functional simulation is occasionally required, so that the prototype can be evaluated properly. For example, some dummy location data and mapping might be displayed, or pre-recorded videos play in place of a live webcam when a button is clicked. Sometimes this can turn simple horizontal prototypes into evolutionary prototypes, where the prototypes slowly transform into the final system by adding more and more functionality.

For simple projects, this may be desirable. But this approach can undermine the greatest benefit of a throw-away prototype – that the rough and simple nature of rapid throw-away prototypes allows, and in fact invites, large structural changes with very little risk or effort, before any coding takes place.

 

Vertical Prototypes

Verticals seek to demonstrate the complete functionality of a single feature, or a small set of features. They focus deeply on technical issues and are rarely shown to potential customers or non-technical stakeholders. Occasionally, they expose problems in a sub-system that may require changing the scope or the number of user interactions. The aim is to make sure that it’s possible to implement all the core features envisaged for the completed project. Where the product innovation is primarily a novel arrangement of common technical practices and solutions, there is less need for vertical prototyping.

Vertical prototypes are only used early in the cycle where proof-of-concept for a core feature is needed. Data processing volume testing, network sizing and latency tolerance, performance engineering, load balancing, code optimizations – identifying or solving problems “behind the scenes”.

These technical prototypes can be created in parallel with the interface, or built in advance of the user interface, or built after the interface is designed.
But they are commonly built to prove a concept, then thrown away.
If built early in the development cycle, it is not always known which platform/language will be used for the final product. Verticals generally do not allow for interactions with other features, use cut-down or dummy databases, and code is rarely optimized. Trying to re-use this code would take more time than starting fresh on the final build.

Modular Development

Where the end product is a series of modules, rather than a single system, it may be better to “start deep”.

Vertical prototyping may be the best method to use. Individual modules can be built with little regard to the ‘big picture’ as exposed by horizontal prototyping. Where the general architecture has been decided in advance (e.g. objective C on iOS) then it may be most efficient to adopt evolutionary vertical prototypes – simple operational frameworks that can be iteratively refined.

The Next Feature Fallacy

A few weeks ago, I read this tweet, and found myself nodding my head in vigorous agreement. The Next Feature Fallacy: the fallacy that the next feature you add will suddenly make people want to use the entire product. — Joshua Porter (@bokardo) May 14, 2015 For people who love to build product, when something’s […]

Source: The Next Feature Fallacy: The fallacy that the next new feature will suddenly make people use your product at andrewchen

How to solve the only problem you have

Here are some fake problems you think you have :

  • What shall we call this?
  • What color is the logo?
  • Should we include (insert desirable feature here)
  • Which blog platform is best?
  • Facebook or Google advertising?
  • Is C++ better than PHP?
  • Should we get an office?

Here is the only real problem you have :

  • Does this idea solve a problem for people who are willing and able to give me money?

 

How to solve the only problem you have :

Take stock of what you have in front of you. I assume that you have an idea – one that you generated out of your own genius, or something that your cousin told you at a party, or some variation on an idea that someone else turned into a business.

Try to write it out in one or two sentences.
Here’s an example…

“I’m going to sell an Android App to predict future weight loss, based on a person’s past failed diets.”

 

Will this idea solve a problem?

Yes, you say, of course it does. But, think about it – how do you actually know that it solves a problem? Maybe people don’t want to think about past failures. Maybe they don’t want to record numbers every day. Maybe they don’t want to know their future. You need to find out.

Will people pay to solve this problem?

Let’s assume that you’ve asked a bunch of people if they would like to be able to predict their future weight loss. A few say this sounds great. But maybe, when time comes to actually purchase your app, they decide that they really want to spend money on chocolate rather than some shiny new software to tell them they’re going to fail again anyway.

You need to come up with a way to ask them to actually pay for your solution – you will never know if you have an executable idea without doing this.
If people hand over money, you know you have a market for your product.

Is it possible to make this work?

Don’t ever ask software people if something is possible. Of course it’s possible. Every coder knows that they can make anything happen – given enough time and money (and enough bubblegum and string). Some of them probably can make magic happen.
So they will invariably say something like “Sure, this is awesome, and I reckon we could build this in a few months, and for too not much money. Half up front, and half on launch.”

 

Do not do this :

At this point, a lot of first-time entrepreneurs say “Woohoo, some people I know agree that this is a cool idea, and a developer said he could build something like this for $40K. I should go ahead and just do this thing!” Commit to the dream.

No.

 

Do this instead :

Figure out the things that are special about your idea. Do this by listing all the awesome features, and then one by one, take features off the list, and stop at the point where, if you remove one more feature, the whole idea evaporates in a puff of smoke. What you are left with is your core feature set.

 

Don’t design pages or screens at this stage. No colours, no branding, no perfect layouts. Sketch up every single one of those core features in terms of an interaction between your application and the user… e.g. (a) record my weight, (b) create a list of common meals, (c) record what I ate today, (d) note the result, (e) join a support group, (f) delete last years results, (g) scrub and start again.

Each of these “touch points” (computer/human interactions/interfaces) needs to address :

  • How do you get to this interaction (e.g. from a floating always-on menu, or in response to a particular set of circumstances)
  • What is the user input (e.g. a whole number of kilos, no decimals)
  • How the app responds, what to expect (e.g. displays projected loss based on a mathematical formula.. pokes out it’s tongue.. calls an ambulance…)

Along the way, make sure to ditch anything that really isn’t needed to define/test the concept. For example, you really don’t need to have a secure login system. For now, you can just take it as read that when you launch, that would be desirable. For a first pass, choose something simple like entering a unique username. You do not need to add an avatar, nor link up with Facebook or Tumblr – irrelevant, strike it from the list.

Then do this :

You have your “core features”. Now you need to answer the next piece of the puzzle… can this be built?

Don’t ask a software engineer if it’s possible (see note above). Sidle up to a coder. Offer them a small but reasonable amount of money, or a piece of the action. Ask them to build a proof-of-concept model, based on your “touch points” flash cards. Nothing fancy, no colours or polished wording, just the basics.

The only brief should be “build something really simple, using any coding language you like, and any database, that demonstrates positively that all of these features (“touch points”) can be implemented on (platform like desktop, tablet, iPhone). It can be ugly as sin, but if something doesn’t work, then they have failed to build anything useful for you.

In most cases, you can get a rough working prototype in a few days, because you have a short list of well-defined expectations. No guesswork required, no need to pick just the right shade of lavender for the backgrounds. If you outsource through one of the freelance services, it’s not going to be expensive. But feel free to ask your geeky cousin who’s still in high school, as long as he knows how to write functional code. You’re not going to use this for your launch product. Don’t sweat the details.

Then do this :

If your geeky cousin or cheap contractor was not able to make something that jumped through your short list of essential hoops, then you have scored a victory. What, you ask, but isn’t that a failure?

It is a definite WIN if you can scrap an idea early, which can’t be executed. Take the afternoon off, open your notebook, cross that idea of your list, turn the page to the next awesome idea, and start over. The name of the game is to reduce your risk and generate revenue – it is not the process of forging on regardless with an unworkable or impractical idea.

You have now addressed the question ofCAN this idea solve a problem for people who are willing and able to give me money?”

 

Then do this :

If you get this far (a well-defined group of people think it’s a good idea and addresses a pain point. You have reduced the concept to a few core ideas, and you have tangible proof that it can be implemented at least on a rudimentary basis), then the next thing to do is discover if there is a real product/market fit.

 

The thing you are trying to discover at this point is :
“CAN this idea solve a problem for people who are willing and able to give me money?”

You have a rough functioning prototype. You have covered all the pain points of your defined audience.

Ask people to pay (yes, pay for the shitty prototype rough system you have). To fork over their chocolate budget.

You will probably have to come up with some sort of equally rough and unpolished sales pitch and marketing message. You may choose to buy AdWords, or retain a sales person to generate some leads.

If you can do that, then you have created your MVP (Minimum Viable Product). Take note of the fact that the working software you have to play with at this point, the really simple Android App (or HTML web app approximation that kinda works on a phone) is going to be NOTHING LIKE the final product.

And, really take note of the fact that the MVP is not just the software – your MVP is the problem, the software solution, the story, and a price point that generates real sales – in equal parts! Actually, all you need to demonstrate is a willingness to pay. If people click on the “pay now” option, then you can always have a response like “Thanks for your enthusiasm, we will contact you when the launch happens, and here’s a discount coupon.”

You may think that if you had a final, complete, polished version that it would sell a zillion copies in 24 hours, but the truth is that if you can’t sell the rough prototype, then it’s going to be an uphill battle to sell a polished final.
But, if you can sell this rough prototype, then selling a polished final version at launch will go 100 times easier!

 

If you have validated your MVP, then you have solved your only real problem.

The rest is downhill coasting. Well, not exactly downhill, but now you’re armed with confidence that you have something revenue-positive, with a definite market, and that the idea is executable.

You can go back to figure out the naming, branding, logo colours, blog platform, etc etc etc . You probably should do a second cycle of prototyping before committing to your final beta-release version. Some AB testing, some UI / UX, some hardware costings, etc etc etc

The goal is to deliver your MVP to the marketplace ASAP.

“Here’s something we built for you. Would you like to buy it?”

 

 

 

 

Once upon a time

OfficeWorkThe industrial era was a time where people learned a useful skill set, took a job, crafted a lifetime career, and retired on a pension. A lot of people found jobs that allowed them to coast along doing the same old stuff for decades.

Then the world discovered computers and joined them together, and created an efficient communication system, which destroyed most of the economic barriers of physical location, timezone, language, local scarcity. And connected individuals into new tribes based on interests, values, attitudes – instead of politics, race, wealth or gender.

The transition to an information economy is happening fast, will be extremely disruptive, but will also be “values-driven”. Consumers are already much more careful about who they buy from and whether they align with their values. The old gatekeepers aren’t in charge anymore, and if you have something of merit to bring to the table, the public can now judge it directly. And reward you for adding value to their lives.

Executable ideas will be the most valuable products of the 21st century.

Ideas are nice, but only executable ideas produce economic and social benefits.

The laws of impermanence now rule the marketplace.
Execution rules.

Entrepreneurship and self-employment are the strategies most likely to succeed.

Startup companies and individual entrepreneurs are the powerhouse of the next economy.

During the industrial age, it took huge amounts of capital to set up a new company, to realise the economies of scale, and so the concept of small businesses being successful was effectively “bred out” of our way of thinking. That indoctrination is beginning to fade, because the industrial process has reached its original goal (to make stuff cheap and plentiful). Just like we don’t think about how to grow food any more, we can stop thinking about how to build physical goods.

There are tens of thousands of startups – working right now on new systems, tools, solutions, methods, all focused on solving the multi-faceted needs of fellow human beings into the near (and far) future.

They are the adventurous ones. But soon they will be joined by millions more, as the industrial companies they work in give way to the digital information economy. Family businesses, sole traders, all with an imperative to innovate or die in the global network. And the result will be an amazingly diverse ecosystem, constantly evolving and growing.

Reduce risk, increase communication, get measurable feedback, and be quick to market.

All these things can be achieved by defining the MVP (minimal viable product), and using a well-selected series of prototypes before going to the expense of building “version 1.0” for launch.

Prototypes can range from the roughest of sketches, to fully-functional mockups – but which ones are appropriate in which circumstances?

I believe that a lot of great ideas die before they reach the market, because they fail to make it through the very early stages. This is a terrible waste of time, money, and progress – and a source of pain.

Only include what you can build

Don’t prototype features or functionality that cannot be implemented.

How many times do you get a nice looking PhotoShop design as your brief? It’s nicely sliced and diced ready to roll. Sweet. You are really happy, because the client has clearly got his shit together.

You start translating into HTML/CSS or binary code, or whatever you use, and about 24 hours into it, you’re looking at the details of, say, a harmless dialog box. This is the first time you read the little 8pt notes – and the wording says “search our suppliers’ databases, and return a formatted word document summary”.

Wow, you think, that’s an awesome idea.

The only trouble is, (a) the suppliers do not grant access to their database, (b) most don’t even have a searchable database, (c) there’s no way on God’s green earth that you are going to be able to format in Word, and (d) would all these suppliers actually allow you to munge their data in with their competitors and displayed on your app as your own?

Bother. So you go back to the client, ask what this little dialog means, and they say “Oh, well, we thought this would be great on the demo. It will let our potential customers see the awesome stuff we have in mind for the launch release.”

“But what about a, b, c, & d (above)?”,  you ask them.

“Oh, well a, b, d, I guess you’re right, but we saw someone else format things kinda like Word once. So (c) is proof that we can do it. Maybe you can do one of those cluster-the-cloud techie things. You know.”

This project not only raises 100 red flags, but it’s this sort of thinking that will come back to bite you in the bum. Not during alpha or beta phases, but probably about a week before the launch party (once all the marketing budget has been locked in).

The early test audiences, focus groups, pre-sales results might be totally based on this one awesome feature.

The one awesome feature that nobody has any clue how to actually build. (Well, there’s a rumour that some guy in Slovenia can do it, but only if you get his whole family residency visas, and hire his cousin.)

But when you get to launch, everyone says “Where’s that awesome killer feature we saw in your prototype? The one that I’ve been telling everyone about. Show us how it works, and we’ll drop shit-tons of money in your lap right this instant.”

“Well,” you say “we removed that since you saw the prototype, because it just didn’t work. Only a couple of our suppliers could provide data, and only if the other was hidden, and of course you can’t format 700-column tables in Word, and there were some legal issues. But hey, look how you can pick your own avatar in the social sharing screens…”

You forgot the “Viable” bit of the MVP.

When you are building a prototype, and you don’t quite know if some small part will work, then don’t show it to anyone until that small functionality has been proven. I’m not talking about common stuff that’s a variation of something you or everyone else has done a dozen times, just the stuff that is a kinda-new idea, or if it’s central to your concept.

Try leaving it out. If your idea still works, then it shouldn’t be included in your MVP prototype. If your idea just doesn’t work without it, then you’ll need to figure out how to make it work, before you go any further.

You might like to build a Functional Model first – some simple little single-purpose bit of code that demonstrates that you can, indeed, hook into suppliers databases, and format the results. You don’t need anything pretty, and nobody is going to look at it. It’s just a proof-of-concept tool.

Then you can go ahead and happily make a prototype, complete with the pretty little dialog box – without your awesome feature working at first, because you have proven to yourself that it will work in the end.

Or, if your Functional Model fails, then you don’t even have to build a prototype of the app at all.
Cheap, quick, risk eliminated.
Time to try another idea.