Creating a mid-term prototype to unlock your team

How vision and near-term prototypes were not enough to align the team.

The mid-term prototype

A few months ago, we had the opportunity to work on a brand new product which involved launching a net new product to the market. We started with a three-year vision prototype to get buy-in and then immediately went into designing our alpha release to get engineering started. Moving from ten thousand feet high to deep in the weeds confused our team because we didn’t give them anything in between.

Vision and near-term prototypes are not enough to align the team.

We first developed a 3+ year vision for our product area that was reviewed by the team and approved by leadership. This helped us create excitement and get the investment we needed to fund the idea. You can read more about our process to create a shared vision in our “Create shared focus with vision prototypes” recipe.

Assuming that everyone now understood where we wanted to go, we switched gears and put our efforts into what we’re shipping first in our alpha and beta releases. We set up launch milestones, and created high-fidelity mocks for the user flows required for each launch. In contrast to the vision prototype we created initially, these were very focused and targeted to solve specific use cases.

We reviewed these mocks in design reviews with engineering teams and leadership again, but the overall sentiment was confusion and misunderstanding. We heard questions like “You’re showing web, what would it look like on mobile?” and “Why is the experience so hard?”.

After a few meetings like these, we were in shock. How is it that leadership and the core team agreed (and were excited!) about the vision but were confused about our alpha and beta flows? It turns out there was a missing layer.

The unexpected missing layer.

At this point, we had a vision prototype meant for long-term vision and a short-term, high-fidelity prototype meant for engineers to build out user flows, like what happens when you click a button. After meeting privately with a few folks on the team, it turns out no one knew what we were going to ship one year from now.

We realized we needed a mid-term prototype that was rooted in reality and could demonstrate what we could build with our resources within one year.

We blocked two weeks on our calendars and got to work. First, we took our vision and removed all the bits and pieces that we knew would not make it for our initial launch. Second, we looked at how the information architecture and overall navigation would fit in our apps. And third, we built a prototype that showed what we could realistically make available to the public in the next year.

A mid-term prototype helped us move forward.

After a few rounds of iterations, we brought this new prototype to our core and leadership team. Our goal was to align on what we could GA within one year. We made it clear that we did not want feedback on individual flows and that what we were showing was not a vision.

The outcome was what we hoped for. People were aligned, and there was a shared understanding of what will be launched for our first release. For example, we showed a clear strategy for our new IA across all clients, including mobile, that showed precisely what we were planning on doing for the first public release. With everyone aligned, we were ready to move back into execution mode at full speed.

Recipe

1. Start your project by creating a shared vision and getting it approved by your leadership team.
2. Block roughly two weeks on your calendar to work on your general access (public) release. This will be your one-year prototype, where you show what will be launched based on your vision. Note that you don’t need to block your calendar for this prototype fully; make sure that this is your primary focus during this time.
3. Get the relevant stakeholders together (in our case, the lead designer, product managers, and engineers), and start by creating a list with the main use cases and flows that will make it to your initial release.
4. Take your vision prototype and remove all the features and flows that will not be part of your first public release.
5. Study any missing pieces that are needed to tell your public release story at a high level. In our case, we spent a few days aligning on our overall information architecture and navigation, making sure that it fits all of our apps and clients.
6. With that, create this new mid-term prototype that shows your first public release product. Remember, this is not visionary!
7. Present this to your leadership team and get it approved before moving into the short-term features and immediate tasks.

Ingredients

1. A brainstorming tool like Figjam or Miro to brainstorm with the team.
2. A design tool like Figma to create the user flows and prototypes.
3. A recording tool to easily share a demo of your prototype with your team and relevant stakeholders. We use (and love) Loom.
4. A presentation tool of your choice to build a deck for readout, like Keynote or Google Slides.

Thanks for reading our recipe. Our goal is to share our experiences working together using a short-read format with instructions that you can try on your own — just like a cookbook. We hope you found it useful!

Katie Le & Nicolas Backal