I've had the privilege of working on many challenging and innovative digital projects over the years as a Product Strategist. Throughout my professional journey, I have helped create, organize, and execute many successful websites, apps, and digital products.

I have also seen many “not so good” ideas, and as a result, some failures.

Why do some companies’ ideas succeed and other fail?

There may be multiple variables as to why some ideas succeed more than others. At its core, however, I feel strongly that it comes down to taking an approach towards innovation and development that is fundamentally flawed.

What I am proposing in this article is that we come to grips that the world we live in now is different than it was five to ten years ago due to continuous technological advancements. Our modern world is complex and ever-evolving. Our approach to innovation must be flexible as well in order to stay relevant, take advantage, and reap the benefit of these changes.

Classic Model

You see, there is a classic formula that we've seen time and time again. It’s common that someone comes to us with their idea, along with a business plan, projections in hand, and funding. At this point, any attempt to question or alter the plan is met with great opposition.

Why are people afraid to change course?

It’s taken a lot of effort for someone to get to the point where they come to use with their 'classic model' project in hand. It may have taken hundreds of hours, meetings, proposals, and projections. Any attempt to question that may be seen as taking a step backwards-- which is understandably scary. However postponing failure can be scarier. Ego also typically plays into individuals' reluctance to change course ( but that's a whole different topic that we won't go into here).

Let's first dig into why the 'classic model' is flawed.

Sticking to the “classic model” sucks

Not being open to someone questioning your current plan or an unwillingness to pivot, more times than not will lead you down a sad road filled with rework. You're likely to spend a ton of time building a product under the illusion that all of your assumptions are correct. More often than not, though, all of your well-intended assumptions will be wrong.

This can create unnecessary rework in terms of design, development, marketing, etc.-- which ultimately wastes time and money.

Human behavior is more difficult to predict than Marshmallows

The Marshmallow Challenge is a well known exercise where you take twenty sticks of spaghetti, some tape, a piece of string, a marshmallow and have teams of 4 people build the tallest structure possible, placing the marshmallow at the top, in under eighteen minutes.

Seems pretty simple right? Simply figure out the best way to make a stable structure that can handle the weight of a single marshmallow at the top. In practice it's actually pretty challenging; spaghetti is fragile and doesn't hold much weight, tape is difficult to use when you're building 3-dimensional structures, and then there is the time constraint!

In many of these exercises, the groups vary greatly. The consistent theme throughout various videos, talks, and publications about this exercise being done, is that groups of kindergartners constantly beat out MBA student groups. The kindergartners are often able to build the structures more efficiently and effectively within the time limit.

The MBA students spend so much time planning and spend the last few minutes actually building the structure, only to place the marshmallow on top and watch the entire thing collapse with no time left to regroup and try again. Meanwhile the kindergartners play, experiment, and test different configurations for the entire eighteen minutes. This allows them to build structures that surpass the MBA students' structures time and time again, with the kindergartners' structures sometimes even doubling in height.

There are countless videos of this exercise being conducted. We’ve included one here from Diane Kander's TEDx talk (please note that the specific video is not affiliated with myself or Webonise).

We know that people and human behavior is far less predictable than marshmallows, so why are we jumping into product ideation and development in the dated way of the 'classic model', and similarly to the typical MBA students' process in the marshmallow challenge?

Experimentation, testing, adjusting, and then executing (and retesting) will lead us to stronger products and more successes.

The New Approach

I propose a new approach; one that allows for greater flexibility and continuous adjustment, and one that will lead to greater success in the marketplace and for your company or product.

The fundamental flaw with the “classic model” approach is that it doesn't allow for feedback, adjustment, and/or iteration. Customers don't always behave or engage in ways you may have expected. Not adjusting and adapting appropriately is the main reason why ideas do not reach a point of success.

The thing to realize and remember, is that the world is different now than it was even 5-10 years ago. This means we cannot still approach business, products, or ideas in the same old way. The internet has made our world ever more accessible and wonderful, yet impatient. Your company or product has to be able to not only challenge and disrupt this current world, but also be agile enough to continually adjust and stay relevant. This takes conscious time, consideration, and effort by the stakeholders involved.

First, from the idea phase you move into a prototyping phase that consists of 3 elements:

Building a small set of core requirements (Microplan)
Competitor analysis
Prototyping without coding (using tools such as InVision)

This is where you should start. In doing this exercise it often helps you and your team flush out the intricacies of how your product will work, and how you want it to work. It goes without saying but is still worth mentioning that you should have a differentiator in your product. It should be something that makes your idea and product different, cooler, or better than the other products out there in the market. This process of prototyping can help you further hone and understand that differentiator.

The next part of this is proposed model is continuous testing. It's important to put your prototype in front of users; conduct UX research is essential in this phase. Source users and interview them, survey them-- do anything to help you get data proving that your assumption is correct (or not). You may have to do this a couple times over to get a substantial amount of feedback that will help inform adjustments or pivots in your product.

THEN, once you feel solid about your understanding of how the product should work and function, it's time to build your MVP (minimum viable product) with code. Build a true MVP, free of all those “nice to have” features, a MVP that highlights your differentiator. This is what you're going to take to market.

Once you have your MVP built, let people hammer on your product in the marketplace and get an even better understanding of what to do next. More often than not this will result in you having valuable data to take into your next build! That's when we being more iterations and start up the prototyping process again.

Now, that's given your MVP was at least a mild success. Let's say your MVP was a horrible failure, well then you need to come to grips with the possibility that your idea probably sucks and you should move on. Kidding, sort of. (If you're not sure if it's a failure, feel free to reach out to me directly about it @_erinessex)

Don't worry, be scrappy

It’s okay for your first MVP or prototype to be a little scrappy! The worst thing you can do as an entrepreneur is say “it has to be perfect”-- if you wait for things to be perfect, one of two things will mostly likely happen: a) you never ship your product, or b) you ship something that is flawed anyways. By waiting out until things are perfect in your eyes, it’s very likely that you've wasted more time and money than you would've spent had you tried out prototypes and iterated based on feedback.

"The first draft of anything is shit," - Ernest Hemingway

Instead, don't worry, be crappy!
Make sure your main differentiator in your product is solid and works well, and then test the shit out of it. Don't worry about all of the “nice to have” features just yet. The key is, if your product's differentiator doesn't work, then all the other accessory features don't mean shit!

What we have learned

Innovation is tricky but it is much harder if you develop your product in isolation, without continuous testing. Embracing feedback will be crucial in insuring what you're making is actually cool and something users want to engage with.

The new method has proven to help us in the following ways:

Ideas are able to “fully bake” - Ideas are fully put in front of users before even one developer starts coding. Therefore saving clients money if the direction isn't quite right.
Choose the best dev stack - The stack that your developers decide to build on will be better thought through due to the time that was taken to plan out your idea for your MVP.
No more, “we're waiting on the design team” - Designers will be working far ahead of what developers are working on, therefore eliminating bottlenecks.
Changes are easier to absorb - Having developers start too early on in the process tends to be problematic when there are scope changes. The new model helps the idea “fully bake” then a proper hand-off to developers is possible.
Testers gonna test - Having testers early on in the process can be overwhelming but its crucial that you get feedback that can inform critical design, development, and business decisions.

In Conclusion

I understand building products can be hard and scary sometimes, believe me. But when you shift your approach and put your ideas in the hands of users early on in the process, the real ideas can be uncovered, which creates a smoother and clearer product development life cycle.

blog

The Marshmallow Challenge: Rethinking Our Approach to Product Development