Jurassic Park, Founder’s Syndrome and Design Sprints

Ian Latchmansingh
5 min readMay 7, 2018

If you haven’t seen Jurassic Park, I feel sorry for you. But to put it succinctly and in a design context: Jurassic Park is about product validation. Spoiler alert: in the film, John Hammond brings a team of scientists to evaluate his prototype dinosaur park and then everyone gets murdered by velociraptors.

This was right before the murdering started.

I decided to write this article after departing from a now-defunct startup that struggled to adopt Design Thinking and Sprints in a productive way. Our founder was there for the birth of every T-Rex of a feature we designed. Ultimately, we should have been asking:

“Is creating another T-Rex something the world needs? Is there a way we can improve on the existing T-Rex to make it more useful and perhaps less bloodthirsty?”

This is pretty much what feature deployments looked like at our startup.

With the hindsight of about 20 years of design process innovation, I can safely say that Jurassic Park could have avoided about 80% of its crises if they had conducted a Design Sprint to work out the kinks. But, it was the 90’s and the idea that anything was intentionally designed is hard to believe.

I try to keep my posts PG, but — what the fuck is this?

The one caveat to this being that John Hammond should be optional.

Now, that’s not true for every organization. I’m sure there are some people who really embrace product prototyping and validation. In my experience though, having a founder decider is something that should be avoided in some scenarios. We’ll dig a little deeper into what can go wrong, why it happens, and ways to work with these scenarios. And also there will be dinosaurs.

The founder doesn’t have the patience to invest in this process.

John Hammond doesn’t care how he disrupts your precious work.

Congratulations! You may regret this, but getting the founder to accept an invite to a minimum three-day meeting is a big accomplishment. No matter how much prep work you did in persuading your organization to apply this process, you may likely be met with skepticism at best. The founder doesn’t always adhere to your rules either, so be prepared for some possible frequent interruptions bookended by uninterested smartphone usage.

Solution: Highlight deliverables and never forget, money talks. If you can make the results of a sprint feel tangible and attach some dollar amounts to how much money these processes can potentially save (or generate!) you are more likely to hold their attention.

The founder is too attached to their own vision and unwilling to change based on prototype feedback.

No matter the carnage, the founder is always right and you’re doin’ it wrong.

This is one of the keystones of Founder’s syndrome: any challenges tend to underscore their own beliefs and act as an imperative to take greater control of the minutiae of the product. In a sprint setting, this is usually results in dismissive reactions to your testers. Founders can be quick to subscribe to the Faster Horse ideology, but underestimate the real-world learning curve between their vision and the status quo.

Solution: When you conduct testing, ease the blow to your founder’s ego a little by asking for “advice” and not feedback. This frame of mind helps the tester feel like they are partnering with you (and they are) to improve your product.

The founder considers themselves to be the authority on technical decisions.

See. It’s the same thing.

This is where you might encounter the founder ignoring the sentiment of specialized attendees (design, engineering, marketing, etc.). They may also take this a step further and criticize or — in extreme cases — remove the offender from the exercise. They might cite other products that “went viral” or had allegedly short-lived beta versions as proof enough that these experts are less integral to the org. Having these people on staff is sometimes a checkbox for investors in their mind.

Solution: Be transparent about what your role is and what your department has been up to. It’s likely that they don’t know what you do on a granular level, so speak in terms that are in plain language, too. Once they gain a fundamental understanding, they’ll trust you a bit more and feel proud when they do reference something technical properly.

The organization has structured the sprint to include people loyal to the founder.

To be fair, it’s not always a lawyer.

Much like the lawyer in Jurassic Park, the “Donald Gennaros” of your organization are people who have worked with the founder in the past and are there to reinforce the founder’s own beliefs. No matter how many things go wrong, they will always sit on the toilet of loyalty (a loyalet?) until the Tyrannosaurus they created eventually consumes them whole. This will make voting during sprints particularly difficult as they will gravitate to the founder’s solutions or the founder may only endorse theirs.

Solution: Become an expert. SME’s that have little experience in product design can still be very useful. They are often happy to share their experiences and sources of knowledge around an industry or topic that is foreign to you because hey, we all feel good when someone considers us an expert.

It’s important to remember that John Hammond is not the villain.

He had a lot of great qualities that enabled him to act on his vision and he was sincerely interested in being involved in every aspect of the creation of a product. Don’t let the founder’s behavior skew your Design Sprints into meaningless, sisyphean tasks. Cure them of their syndrome.

Or this may happen to you.

“Loyalet.” Yeah that’s a good portmanteau. CC BY 2.0