When to pivot

• Tweet
• Pin It

Pivot is the most overused word in business. It is mistakenly used to cover up mistakes or to justify expensive failures as learning experiences. This is only OK if the team had set out to learn that stuff. If not, it’s a cock-up, not a pivot.

As Eric Ries said of his product failures in the early days of IMVU,

“If the goal of those months was to learn important insights about customers, why did it take so long? Could we have learned those lessons earlier if I hadn’t been so focused on making the product ‘better’ by adding features and fixing bugs?”

Ries is right. Our objective is not to make a prototype better and better until we ship it. It is to learn what we need to learn from each prototype to inform our final design decisions. Sometimes, that will involve keeping the code base. Sometimes, that will involve throwing away the code that we have built once it has fulfilled its learning function. This is never easy. It is important. The purpose of a prototype is to learn. It is not to be the base of your product.

Designer Daniel Cook says,

“The spirit of prototyping is one that is best suited to off-the-cuff hackers and geniuses. In mere hours, the prototype needs to be playable such that the feedback cycle can begin. Hackers, though deadly in the long run, will cobble a prototype together by hook or by crook. The code will stink, but it will work.”

He advises, and I agree, that you set strict limits on architectural work. If you think you might need a robust conversation system, hack it together, don’t future-proof it. Odds are you will realise that this system is overkill for your hidden object game or first-person shooter, and you should throw it away. As Cook says,

“The goal is to create a prototype that can be critiqued, trashed and thrown away. The goal is not to create a finished product. There is a time and a place for spending copious time on your architecture; the prototyping phase is not it…. Depending on the personality of your team, this can be one of your biggest project management challenges.”

This is particularly true for teams that are transitioning from workfor-hire and which are dominated by a production mentality, rather than a design mentality. Design-led teams risk never getting the game made, whereas production-led teams risk making a game that nobody likes.

This is an extract from Nicholas’s new book, The Pyramid of Game Design – get your copy here!