So many aspects in our lives are based on other people’s visions coming true. Going through history, visions which became reality changed our lives dramatically, and as technology progresses, this becomes more and more true.

Vision — a thought, concept, or object formed by the imagination (Merriam-Webster).

Being a product manager is all about being able to turn a vision into reality. We all know these a-ha moments when the vision strikes us (my vision creator is the shower, what’s yours?), but, what’s next?

Many times I find myself visioning a full E2E experience, and it’s crystal clear to me what the outcome will be. Now, how the heck am I going to spill it out and share it? Until we are able to project our thoughts (or a Dumbledore Pensieve becomes real), this is an art to be mastered — and a crucial one for us product people.

From my experience, there are four steps for turning a vision into reality.

Step One: Begin With The End

Usually it is like a vision projecting in my mind, I can see the system running and a user using it, what it feels and looks like. So the first thing I do is simply write it down, with as many details as possible, describing the super super happy flow. It is usually a description of how, what, why, who.

When you do this — you gain two things:

• You took it out of your brain and turned it into something you can easily share.
• You can now read it and refine it.

At the end of this step you usually have the super happy flow described in somewhat of a bird’s eye view. Now you can do one of two or both:

1. Start refining it and breaking it down — finding the loopholes and open issues, analyze the customer journey and understand how will it be impacted etc.
2. Share it to get feedback — but be aware that there are many unknowns or open issues to be addressed. When you share it — make sure you present this disclaimer plain and clear.

I prefer to refine it first as it is pretty raw, and when presented in such a raw state, there is a tendency to focus on the open issues (which might be a lot) rather on the big picture.

Step Two: Refine It

Now that you have the super happy flow, it’s time to detect the holes and understand the complex parts.

From my experience there are a few paths you can choose at this point.

They are somewhat similar, but serve different purposes.

The outcome of both is turning the words into something visual and often one is used to get a clear high level understanding as a first step to the final visualization.

The main reason to do this is that it is much easier to grasp, identify and solve gaps and issues when you can view it.

Pre-COVID, I used to have a big white board in my office — as I found it enables me to visualize what I needed.

The work from home enforced me to find a solution as a big white board wasn’t something I can hang in my kitchen office…

So I’ve went with Miro.

The Visual

Visual — Something (such as a graphic) that appeals to the sight and is used for effect or illustration. (Merriam-Webster)

Let me take you back to a situation you might find familiar:

I had a vision which was very clear, but was super complex. I was stuck. What’s next? I understood that there are many options and complex decisions.

So I simply started to throw it all in a big mind map in Miro.

The Mind Map

Slowly, I started to identify the open issues, decision points which I need to address.

It was clear how to solve some , which created another branch in the mind map, while others were items to take with the team. The mind map helped me to refine the complexity, which enabled me to understand where to focus and which flows I have.

The Flows

I often scribble wireframes as part of the first step. If I did not do it then, now is the time. These wireframes are important as they enable me to add the missing visualization. My suggestion is to work closely with your UX team to begin with. Recently I had to work on a new concept, for which I’ve joined forces with our head of design from day one. So, basically from the start we simply turned the vision as we discussed it, into wireframes.

Then I used these wireframes to create the different possible persona based flows. This was of course the happy flow with screenshots of the wireframes. For the first time my vision (in this case our) was transformed to something we could visualize. Once we had this basic flow, I added sticky notes in each step. I used a color coding system to make it clear where to focus and what the issues are.

The color coding was based on:

• Red — open issue/s which we need to discuss and find a solution for.
• Yellow — decision point — something to which the solution is clear, but has a few options. The sticky note displayed the options and my preference.
• Green — To emphasize a decision taken or add an additional explanation.

What was the outcome?

A persona based visual of the vision, with a clear view of all the open issues (I could think about), options to be decided about, and decisions taken including the WHY.

This is the point at which, in both methods, once done I could take it with my team — Developers, UX, Product — for feedback.

But, before I did that — I added one more thing — I created a release plan.

In this part, I simply decided which personas and relevant E2E experience I want to deliver — and remember start with the end!

I simply described the E2E flow and what will be delivered. I’m sure you are now asking yourself— how far forward did you plan? Well, since we are working in quarterly releases — I created a plan for two releases, and the rest was a backlog. I know that the backlog is something that will most probably change, but it’s critical to have it for conveying the plans ahead.

I had the story told in words, I also created the visual flow for each release, with all the sticky notes and everything. I also described the GTM messaging, KPIs and all.

Now I was ready to present the vision and get the feedback, why?

Because I had the following:

The big longterm story — this is where we want to be and even more important, Why. What are the issues we need to discuss that I’ve already identified.

How I want to execute it — For the next two releases, what are the deliveries, what are the open issues I’ve analyzed, which of the open issues in the long term I want to solve, how I measure success/failure and how we plan to communicate it to the customers.

What we are NOT going to build — What is going to be in the backlog, but is still part of the vision, for now at least. The backlog should come with a big disclaimer: I want this to be built, but I understand that it is subject to change as we progress and deliver the first parts.

Step Three: Present and Learn

How is the presentation done, and to whom?

I want to start with the more complexed part — The whom.

There is no one text book answer here, and I guess the best answer is: It depends. From my experience every stakeholder should be part of it. Whether all together or split, this is subject to many aspects that are company specific in my opinion. I think that the best practice is to have the Product team and at least the relevant RND leaders in the same room together. one thing is certain — I wouldn’t present it to other stakeholders (Leadership, Sales, CS) before I’ve had a session with RND.

Just make sure you present it to the:

• RND — to understand technical issues, hear about ideas for a simpler solution.
• Product and UX — personas, experience wider view and knowledge of other affected parts in the product.
• Sales — how will this enable them to increase their sales and reduce the cycle time.
• CS — hear the voice of the customer.

The Presentation

As your vision started, start in describing it. Take the audience through the steps in the visual flow. Set expectations and EXPLICITLY note that this is the super happy flow and any other relevant disclaimers. Explain the sticky notes colors, and describe the issues for each step — but do not open a discussion.

Once the high level is done, decide if you want to:

Open a discussion about it OR present the plan and only then, open the discussion.

In both cases, when presenting the plan, always begin with the full story, disclaimers and then the visual flow. Same as when presenting the big story. Don’t forget to present the GTM and KPIs!

Step Four: Fix and Create A Plan

Once all feedback is gathered and action items agreed, our head of design and I finalized the flows:

All the red and yellow sticky notes should be resolved and removed.

Now it’s time to do three things:

1. Create a detailed story mapping based on the agreed flows.
2. Finalize the UX and have a detailed UI.
3. Collect feedback from your users and align the UX and plan accordingly.

Once you have this — all is set for final review and development.

So, what has just happened?

Disclaimer first — The process above can be part of the design sprint process. What I’ve described is how to do it when you are not conducting a design sprint.

I had an idea and a vision of it during the shower 😁

I started with describing the vision in words, transforming it from a thought to something substantial.

I then created a detailed flow and identified the open issues and decision points, based on personas.

The flow has two dimensions:

• High level
• Breakdown to release

I then reviewed it with the different stakeholders and adjusted it based on their feedbacks

Last but not least — a user story mapping.

And now you simply need to pass it on to the RND for development!

I’d love to hear your work process and your comments.