How to Foster Ongoing Shared Understanding During MVP Development

By admin
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.


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


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


, 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


, 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.