Innovation has a cycle of expansion and consolidation. Your company, teams, products and tasks can be too.

I am comfortable with the unknown and am often in missions to help (new or old) projects do new things in a new way. They often are a whole experiment in themselves.

In my “Agile” team, we’re given specifications like: I want X to do Y in such way. I’m perfectly comfortable with that and my team is able to deliver value continuously. When it’s “too new”, we sit down and guess, think out, hypothesise the technical answers.

In the office in front of mine, they’re given a slightly different kind of specifications.

The Scientific Method specifications

• in context A we face problem B and solve it with C
• we will give you X weeks and Y€ to come up with a different way, likely Z
• experiment will be used for D weeks on E% or F thousand customers
• we currently pay G€ and have things work in an average time of Hhours
• your experiment will be a success if G or H go down by at least I%
  • if it works, we plan to expand your experiment for more time/customers/contexts
  • failing that, we will revert to the old ways

Their projects look like they always work great and satisfy everyone, customers included. Why wouldn’t they? They know exactly how things work and what improvements look like.

The very fact that such a spec arrives shows the stakeholders are already OK with investment: they have to pay to play, they know it, and they budgeted how much they could spend.

So don’t try to replicate the rules, but try to ask the same questions. It’s all about knowing your business, and making other people know the stakes too.

Bonus idea: have some idea log, wiki or whatever house rule so you can add: “we have tried such and such in the past and it didn’t fork for (we guess) these reasons”. and revisit the list from time to time: it’ll give you more ideas, and it’ll be a great way to know if some assumptions changed and if it might be time to revisit ideas again.