“I have an idea,” I said to my colleague, holding a freshly made cup of coffee.

It was a regular day at the office. We went for a coffee break — a part of the day dedicated to informal brainstorming and sharing ideas. And let me tell you, working on hardware prototypes at General Electric, we had a lot of them.

I continued, “I know we work mainly on hardware prototypes, but what if we took some of the best practices from IT and applied them to our processes? If we take the best out of Agile and add it to our project management practices, we might help our customers better!” I added.

I waited for a response from Łukasz with anticipation. It was vital for me to know what he thought — he was leading another team, and his support would make or break the initiative.

“Hmm, that’s interesting. Let’s see what you’ve got,” he replied.

It was a starter for a lengthy talk about Agile, Scrum, Kanban, and product and project management. We discussed how we could get better outcomes by redesigning transparency, inspection, and adaptation in our process.

It turned out it was stimulating not only for us as soon more people joined the conversation, and it got me even more excited to take the next step.

I went back to my desk and started sketching out the plan.

STEP 1: The Problem

Ideas often describe a product or approach that can make someone’s life better, which carries a significant risk of focusing too early on "what" — the solution — and "how" — the plan.

For example, “Let’s introduce Scrum! Next quarter we’ll be ‘Agile’ to perform better!”

There are major pitfalls of an idea stated this way. First, it's vague — it doesn't point to any measure or character of improvement. Second, you might end up solving the wrong problem right.

You can prepare everything very well — train the entire team, hire an Agile coach, set up Jira, and introduce daily scrums. But if your only goal is to market your organization as “Agile,” you forget about the problem and miss the opportunity to improve as a team.

Hence the most critical step is to start with "why." 

Mark my words, you should always start with "why." 

Still not convinced? Then Simon Sinek’s presentation on “how great leaders inspire action” is a must-watch.

Long story short, when you start with "why," you focus on a problem to solve and the purpose and motivation behind it. No matter how well-engineered your solution is and how terrific it looks, no one will use it if it doesn’t solve any problem. Period.

So, the first step is to define the problem fully. Write it down to have a clear guidepost for the future. You must remember why you’re taking specific actions at every step of the process.

When you identify the problem, you need to understand

• the core of the problem,

• the reason why it is a problem,

• who experiences it and how often, and

• what are the current methods of solving it.

Going back to my story — we had an excellent understanding of the situation. We could collectively articulate the problem definition before taking the next steps. We wanted to improve a particular part of our work, and it was essential to find out what slowed us down.

At the time, we used many project trackers to manage processes. We had difficulties getting accurate information about projects and ensuring smooth hand-offs across many global teams.

How come?

Maintaining the data was difficult, and every prototype had a random ID. We had to track orders, financials, peer-review documents, project charters, user manuals, reports, and other documentation. In the meantime, we had hand-offs, daily firefighting, new urgent projects, and regular deadlines. 

We couldn’t say whether we focused on the most vital and immediate task. We didn't know whether we helped each other efficiently. We spent a lot of time figuring all of that out.

But it was time well spent — we defined our problem.

Here's a simplified version:

"Due to the lack of a centralized project database, we spend 10% of our weekly time finding, maintaining, and communicating project information, which takes away space for creative work."

As you can see, the problem definition doesn’t say a word about Agile — the initial idea. It doesn't say anything about the solution — the "what" — or the plan to implement it — the "how." But it explains the problem and why it is a problem.

STEP 2: The Hypothesis

"Hypothesis" is a word used most often in science. However, it is also one of the most important words in product development. Any product development! Whether it’s a hardware product like in the example describing my days in General Electric or a software product, which I'm currently working on at Evojam. 

A hypothesis is a statement that we can assess true or false. You write it in a form that lays out your prediction as to what extent the idea will stand up in the real world. It should refer to a metric that we can measure to determine if the hypothesis is true or false.

This step is a brainstorming phase. Making hypotheses might not sound like creative work, but it is. It helps capture the ideas best, enabling you to assess them and iterate going through the inevitable moments of Kill, Pivot, and Persevere.

Our initial idea was about introducing some of the Agile methods to our game. But now, we had to tie the main idea to the problem we defined. And this connection is called a hypothesis.

In a nutshell, the hypothesis we created is as follows: 

"We believe that our team has a problem of spending too much time maintaining project information because it’s complicated and decentralized. If we introduce a redefined, standardized process, a regular Kanban board, and 15-minute daily scrums, our team will spend only 5% time on this activity."

Using a hypothesis like this, you make the goal and the metric clear — decrease the time necessary to update, maintain, and communicate project information from 10%, as defined in the problem statement, to 5%.

The critical part here is to define a "what" — the proposed solution — and "how" — the plan. And yes — it's time for brainstorming and creativity! The hypothesis is a structured outcome from this, usually chaotic, process. It leads to concrete success criteria, describing what we will introduce to move the needle.  

For creating your hypothesis, follow a template:

We believe [subject] has a [problem] because [reason]. If we [action], this [metric] will improve. 

A reasonable hypothesis is clear, actionable, and easy to assess. While I recommend including all essential parts of a hypothesis — the target audience, problem, reason, proposed action, and metric — don’t be afraid to find your way of phrasing it. It's you and your team who have to understand and use it.

A hypothesis is a crucial part of turning an idea into a reality. Most people go through that process unconsciously, but they only paint a picture of a hypothesis in their heads. So, if you want to maximize your chances of success — make it precise and write it down.

We are ready to go to the phase that is usually the core of an idea. The solution and making it a reality, or at least part of it!

STEP 3: The Experiment

So, we got the problem defined and laid out. We formed a hypothesis, determining the solution and predicting the outcome. This step is all about the action. Finally!

It is usually the most fun part. You put a coin into a slot machine, hoping to win! In this analogy, the coin is your effort, time, and budget. The win is the correct prediction in the hypothesis.

The coin is in — we

• created a well-defined procedure focused on transparency, accessibility, inspection, and adaptation;

• organized daily scrums for the entire team;

• created a Kanban board; and

• made sure everybody knows the process and commits to it.

We gave ourselves two weeks to monitor the experiment. It was us observing the symbols twirling in the slot machine. It was almost mesmerizing to see it unfold every day, showing us how the experiment was going.

“Daily scrums? What do you mean? Meeting more often will save us time? It’s insane!”

Change management was a lot of effort, but we needed it. Starting the process, we could only make decisions based on a discussion. It felt counterproductive to meet often, even if it could save time, so we wouldn’t do it. But thanks to this framework, we carried out an experiment that would give us data — a powerful tool to make informed decisions.

After preparing all the changes, we trained everyone and went through the new process. Some people were excited to try it, some reluctant, and some neutral. However, we all committed to it as a team, which helped us understand if the idea was worth pursuing further.

STEP 4: The Learning

The last step is the assessment of the hypothesis. Was it a success? Or a complete failure? Maybe both?

When the experiment concludes, you should have a direct result that you can juxtapose with the hypothesis.

• Did you achieve the goal? Perfect! Let’s explore some more options and try to improve further! Maybe even roll out the process across other teams?

• Didn’t you achieve the goal? You have just obtained invaluable information that you can use in the future. Do you know why you didn't reach the target? Scope out another experiment.

Either way, the results are rarely black or white. Experiments work best when you can distil a specific change and see its impact on the metrics. In our case, we decided to make a more complex change and introduce three new approaches. We did that because we thought none of the three proposed changes would work without the others.

At the beginning of this process, the most important thing is not to push yourself to make a perfect problem statement, form a perfect hypothesis, and conduct a perfect experiment. The essence of this process is the learning opportunity you get with each iteration.

Start somewhere, give your best shot, go through the process, and learn from the experiments. Draw and document the lessons to keep improving over time instead of making the same mistakes repeatedly. Your product will keep growing, and so will your skills!

In our case, there was a significant drop in the time needed to maintain the project information. Still, we didn’t fully meet the intended target.

So, did we fail?

Not really. We saw we were going in the right direction, but we were left with some new questions to answer and some more tweaks to introduce.

BACK TO STEP 1: The Iteration

Have you ever heard the phrase “practice makes perfect”?

In iterative development, it is a mantra. Nothing affects the outcomes as substantially as proper experimentation and testing. The more iterations you make of a product, service, or any other solution, the better the result will be.

Take advantage of the small iterations. Those minor but controlled improvements can build up to an incredible effect.

Can you imagine Graham Bell inventing the telephone with the aim to create the smartphone as we know it today? With voice-activated, video-call functions that can gauge your mood when you speak to a group of people worldwide?

Of course not, it’s impossible. The technology was nowhere near as advanced as nowadays. We have all those tech miracles just because some intelligent, motivated people just kept iterating and learning.

So, trust this process and give it a try. 

Summary

Each idea is worth little until it becomes a reality.

Converting an idea into a reality requires proper planning, experimentation, and discipline. You might skip some of the steps, but only a consistent, iterative process will produce positive results over time.

This framework is about data — your most potent weapon when introducing new ideas. Get inspired by a scientific process and obtain data that can guide your decisions and help you influence stakeholders.

One of the concepts popular in product management is the build-measure-learn loop presented in the Lean Startup by Eric Ries. It embodies the iterative process and talks about the best ways to experiment and learn. The framework I present in this article was inspired by that approach, among other frameworks, i.e. Design Thinking.

So, to summarize, when you have a great idea, don’t just sell it and hope you get support. Instead, go through the four-step framework iteratively and gain traction quickly, keeping maximum control over each iteration.

The four-step framework to turn your idea into reality goes as follows:

Step 1: The Problem — Understand and clearly define the problem you want to solve.

Step 2: The Hypothesis — Set a clear target to assess if the solution from your idea solves the problem.

Step 3: The Experiment — Go through the assessment process of the hypothesis. Try to be as data-driven as possible, collecting valuable data for further analysis.

Step 4: The Learning — Understand the experiment’s outcomes and decide if it’s worth continuing, pivoting, or killing this idea. 

Back to Step 1: Iterate!