How to Foster Ongoing Shared Understanding During MVP Development

In my previous article, I covered actionable strategies for gaining a high-level understanding of what we’re building from the very beginning of an MVP project. Once we've achieved alignment there, we need to get into the details of further defining, designing, and building each area of MVP functionality.

As my friends and colleagues have said before, building custom software is like surfing a wave. We can’t fight the fact that unknowns and change will happen; we have to embrace it — and establish workflows that help us continue to work through new information and adapt while maintaining a shared understanding throughout.

At Viget, we like to establish an ongoing rhythm that facilitates this process so everyone on the team — including our client — knows what to expect. The PM is responsible for refining exactly how that rhythm should manifest (with input from the team), but it’s typically anchored by a cadence of weekly sprints and includes several key rituals that contribute to fostering ongoing shared understanding of what we need to build at a more detailed level.

Weekly Working Sessions

While working sessions manifest differently across projects and sometimes evolve over a single project, these types of meetings typically happen at least once a week and consist of a small group, the core project and client stakeholder team. Working sessions are used to define requirements for the next sprint’s features, and sometimes can be used to share design & development progress and get feedback.

The most effective working sessions include cross-functional input from developers, product designers, PMs, and client stakeholders (i.e., the product owner and anyone else critical to making detailed functionality decisions). That said, the PM often plays a key role in facilitating these meetings, ensuring that we resolve answers to open functionality-related questions, as well as have a shared understanding of MVP vs. future priorities.

Here are some tips I’ve found helpful in prepping for and facilitating working sessions:

Prioritize working session topics based on upcoming feature development planned for the next 1-2 weeks. 

We try to avoid having many detailed conversations around functionality that is more than a couple weeks away on our development schedule, because it can distract developer focus; by the time we actually get to the feature, folks may have lost the shared understanding of how it should work.

Start drafting development tickets to uncover gaps in understanding.

I’ll sometimes start drafting development tickets (or at least thinking through what I would need to put in a dev ticket) as a tactic to uncover key areas for which there may be gaps or potential misalignment in understanding between different folks on the team. I use that to generate a list of topics that need further clarification or discussion before they’ll be actionable, and then bring those into working sessions.

Never underestimate the power of a visual to foster shared understanding.

One route for facilitating discussion is jumping on a video call and just talking through details verbally, which is sometimes the most efficient approach for straightforward topics. But for more complex or less familiar subject matter, it’s amazing how much more efficiently a PM can spark discussion and reach shared understanding when a visual aid is used. This could include throwing a quick diagram together to capture data model concepts and how they relate to each other; screen sharing wireframes or comps and annotating with comments; or screensharing a notes doc and jotting down takeaways or specs related to the decisions we’re reaching. This can help get everyone’s brains in the same place and prompt people to speak up if their understanding differs from what is visualized.

Use shared goals to prioritize new ideas or feedback.

Often, new ideas or change requests will come up during working sessions (remember the surfing analogy?). That’s natural. The PM can focus (or follow up on) our conversations by helping to prioritize new features or change requests based on our shared goals. Often, that may mean putting a new tangential idea in the backlog so we can stay focused on the goal of getting a working version of the product up as quickly as possible. Or sometimes, it might mean adjusting priorities to accommodate a need that was difficult to foresee earlier in the project, but that we all realize is foundational to getting an effective MVP version of the product up.

After reaching a shared understanding via working sessions, that understanding is documented by the PM via development tickets that are confirmed and prioritized via sprint planning meetings.

Weekly Sprint Planning + Standups

Sprint planning typically happens at the end of each week and includes the full project team. (For Viget, sprint planning is typically an internal meeting). Goals include gaining a shared understanding of the coming week’s development work, as well as helping product designers understand what features are coming up in our development queue for the next couple of weeks so they can prioritize their own design work accordingly.

When facilitating this meeting, it can be helpful to:

Get everyone aligned on the big picture.

Briefly recap where we’re at in the project, as well as any key upcoming milestones. This is an opportunity to get out of the weeds of any one feature and reinforce what big-picture goals we’re working towards (say, completing a larger featureset in the next x number of weeks, or preparing for a round of upcoming user testing). This helps empower team members to advise and make decisions in support of those larger goals.

Talk through visuals.

Rather than diving straight into a list of tickets and priorities, it can be helpful to recap our shared understanding of upcoming functionality by screen sharing and walking through design artifacts like wireframes or comps. This isn’t always necessary if everyone already has a shared understanding, but it can be helpful if a) there’s been a lot of prior discussion about how certain features could work and folks may not totally remember where we landed, or b) it’s been a while since we talked through the feature in question. A visual walkthrough can help devs refresh on how they might approach implementing the functionality and give them the opportunity to ask further questions of product designers and PMs.

After everyone has that shared vision, then we can dive into the weeds of prioritizing specific tickets and design tasks for the coming week.

We often pair sprint planning with standup meetings that happen anywhere from 2x/week to daily, depending on the team size and project scale. They’re often YTB-style—in other words, each person shares what they worked on yesterday, what they’re working on today, and any blockers. These can be a helpful supplement to keep the team in lock-step about what they’re working on and surface collaboration opportunities as well as blockers or work dependencies.

After defining and fostering an initial shared understanding of what we’re building during the discovery & sense-making process, we can retain (or regain) that shared understanding throughout the inevitable changes that come up on custom software development projects by establishing rituals that facilitate consistent collaboration.

And while the process of getting there is more of an art than a science, it’s an integral part of ensuring a project’s success, as well as project team and stakeholder satisfaction along the way. 🎨✨