I am a senior product manager in the Public Sector group of VMware Tanzu Labs (formerly Pivotal Labs). I’ve worked on a variety of teams at VMware, ranging from large-scale government and military clients to smaller commercial organizations. Depending on a client’s needs and current product portfolio, a product manager’s days can vary widely. However, workday hours are structured to maintain a sustainable pace and a flexible, healthy work-life balance.
On most days, I pair with my client product manager (PM) for 6 to 7 hours, with plenty of breaks to step away from screens and reset. When together in an office, pairing means sitting next to each other, sharing one computer with two monitors (one for each of us), and discussing what we are working on together. Although each of us has our own mouse and keyboard, one person typically “drives,” i.e., controls the keyboard and mouse. We talk aloud about what we’re doing so our pair can follow our train of thought, ask questions, or suggest ideas.
Now that we’re distributed, pairing typically involves screen sharing via video chat tools like Zoom. Depending on our activity, or where my client is in their product management skills enablement, we alternate who drives and who watches and listens.
Having embraced distributed work, our teams now practice a “remote first” posture, meaning we use remote-friendly practices to encourage collaboration from all our team members regardless of geography or time zone. If even just one person is remote, rather than having part of the team sit in a physical conference room while others are remote, we all use our laptops and headphones in our team Zoom so that no one feels excluded or unable to collaborate. Remote-first practices like this help foster inclusivity regardless of location.
Now let’s dive into what a day looks like for a Tanzu Labs PM!
8:45 AM – Team standup
Every morning, our product team—which consists of three pairs of engineers, our client PM, a client designer, a VMware designer, and me—meets via Zoom for a daily standup. Our team of 10 is spread across several time zones, and we agreed at project kickoff that an 8:45 a.m. ET start time worked well for everyone. Since we are all remote, we prefer to turn on our video cameras for standup. We give our standups by “popcorning,” i.e., calling out the next person to speak after you are done, to highlight our progress from yesterday, our plan for today, and any blockers. Standup typically takes 10 minutes or less—any additional detailed conversations that need to take place are noted, but punted to discuss outside of standup.
9 AM – Goal of the Day
Once we finish standup, my client PM pair and I stay in the Zoom room to discuss and set our “Goal of the Day.” Since transitioning to fully remote, I’ve found it helpful to set a single prioritized goal for us as PMs. We frequently get pulled in several directions as our day progresses; thus, setting a single goal helps my pair and me to be less reactive and more proactive with our pairing time. We utilize Trello to track our priorities and post our Goal of the Day in a single, dedicated column. Additionally, our team has access to our PM Trello board, so anyone on the team can see what we are working on or what might be upcoming.
Our product management Trello board and Goal of the Day
Today our Goal of the Day is “prepare for Outcome-Oriented Roadmap discussion with stakeholders today.” This meeting is in the afternoon, and my pair will lead the discussion. I will step in if he needs any help. We have practiced this, as he is working on his facilitation skills, especially around difficult stakeholder discussions. Since beginning our engagement, my PM pair and I have been working through the VMware Product Manager Playbook; we revisit a section that says “strong communication skills help you lead without authority” so he can mentally prepare for the stakeholder discussion.
Once we have our Goal of the Day, we do a quick scan of the Backlog in Pivotal Tracker, a lightweight tool for backlog management on software development teams. My pair shares his screen and opens up Pivotal Tracker. We are looking for a few specific items when we do a quick scan each morning:
-
Stories that are “in flight,” i.e., still being actively worked on by an engineering pair
-
Stories that have been delivered and are ready for review. We accept or reject these based on acceptance criteria within the story.
-
Stories that are ready for engineers to pick up today. We aim to keep a healthy backlog of approximately two weeks of work. Ideally, every story is independent and contains specific acceptance criteria, necessary designs, and any links to reference sources; we advocate using the INVEST model for story writing.
My pair notices that we have a couple of stories tagged by design for refined design mock-ups, so we flag those two stories as “needs-pm” and will return to them later today and sync with design.
Flagged “needs-pm” stories to review with product designers
Before our next meeting, my pair and I share any personal or pairing conflicts for the day. We do this daily since we aren't co-located and we both want to make sure we’re respectful of each other's time.
9:15 AM – Sync with design
We hop into a Zoom call to sync with our product designers. They have been working on a new user interview script to test some of our riskiest assumptions and have asked for feedback. The script will aim to address specific learning goals that we set for our weekly user interviews. Then on Friday, we will regroup to assess whether we’ve met our learning goals. If yes, wonderful, high five! If not, we discuss why we fell short and what we can do to improve next week.
Cross-collaborating with our product designers on a new user interview script
The product designers open up our shared Miro board (Miro is our preferred digital collaboration tool; check out our handy Miro templates) and bring us to their script. We read through the interview themes and then take 5 minutes to silently generate additional questions that my pair and I would like to incorporate. Next, we affinity-map our stickies of questions (grouping them by likeness) and then discuss which to add into the script and where. The designers will refine the research script, then we’ll utilize it for every interview this week—typically aiming for three to five user interviews per week.
10:15 AM – Break!
During our day, we incorporate frequent breaks that encourage us to step away from screens and rest our eyeballs and minds. I take the pup for a short walk and grab a snack.
Daily sync with Atticus
10:45 AM – Path to production
Next up, my pair and I jump into a discussion around the path to production for our application that my pair will facilitate. Prior to our “P2P” meeting, my pair and I set up a Miro board with a timeline and blank stickies so that we can precisely walk through each distinct step that occurs to get our application to production. The first step is “Code is ready locally,” and we map our end point of “Code is released to production (and viewable by users).” For the discussion, we utilize a favorite Systems Mapping template of mine that my pair has customized for our team. My pair introduces the activity, identifies our start and end goals, and facilitates the discussion with our engineers and security team. As we move through the process step by step, if we reach a step in the Systems Map that is unclear, we highlight it in red and assign a team member to dig into any unknowns and report back. In a track below these steps, we also note what development environment each step lives in as well as any hurdles we might have around data, sensitive information, or certain security thresholds to bear in mind.
Systems Map template
Finally, if our dev and security teams know timings for any steps, we have a third track below to note how long each step typically takes on average. Incorporating these measurements help us to identify any potential bottlenecks or where we might need to allocate additional resources once our app is ready for production.
12 PM – Cross-collaboration with design
At noon, we hop into our Zoom room and ping the designers to see if they can sync up about the stories we marked earlier in the morning for design refinement. In the meantime, my pair and I pull up the backlog and our non-prod acceptance environment. We also want to show the designers two stories that have been delivered today that were user interface (UI)-heavy. Both delivered stories look great to us and pass the acceptance criteria; however, as they both involve some complex UI, we want to make sure design gives their thumbs-up before we hit the “accept” button in Pivotal Tracker.
Design joins us, and we review both delivered stories. They are good to go, so we hit “accept” to let the developers know these can be included in the next release. We then review the couple of stories that need design refinement. Design shares their updated mocks as well as a couple of interaction behaviors to note for engineers. Designers will walk our engineers through the new mock during our next Iteration Planning Meeting (IPM) so they can get a sense of the visual design along with the desired interaction behavior.
12:30 PM – Lunch!
Time to get away from the screens and eat. We typically take an hour for lunch and encourage getting out of the (home) office and away from our laptops.
1:45 PM – Outcome-Oriented Roadmap review
It’s time for our Goal of the Day, our stakeholder meeting that my pair will facilitate. He opens up our Outcome-Oriented Roadmap, which we will be reviewing with our key stakeholders. Our goal for the meeting is to give an update about a new milestone that we will be incorporating after de-risking some assumptions with our most recent user interviews. This means we will be pushing off some work that stakeholders requested in favor of a more potentially risky outcome that we want to solve and deliver first; if we leave this until the end, it could potentially kill the product. My client PM walks them through our updated Outcome-Oriented Roadmap (check out some practical advice on using Outcome-Oriented Roadmaps). We gather some key stakeholder feedback and close the meeting with consensus around our new milestone. Success!
3 PM – Team game break
A much-needed game break is on the schedule for our whole team! We typically love to play either Skribblio or Code Names as a team. We may or may not be tracking a running W-L-T record for our team. After we finish the game, my pair and I take another 10 minutes to step away from our screens.
4 PM – Lean experiments
We regroup to update our Lean experiments tracker with our most recent learnings from user interviews. We’ve invalidated one of our assumptions and want to keep track of our findings. Our experiments tracker lays out all our product hypotheses typically in this format:
[Assumption being tested]: "We believe that…[hypothesis], and we will do/make [experiment]; we will know our hypothesis is valid if [measurable outcome/observable outcome] is present as evidence."
In order to build our hypothesis, we sync with design and engineers on what our riskiest (technical, user, or product) assumptions are. We prioritize the riskiest assumptions and then brainstorm simple Lean experiments as a team. Once we have experiments ready, we use a 2×2 to prioritize which experiments to run first based on complexity and risk.
5:30 PM – Plus-Deltas
My pair and I have been experimenting with daily Plus-Deltas at the end of our day. We each note one “plus” of something that went well, that was exciting, or was particularly motivating in our day. We also share one “delta” of something that we wish had gone better, that was perhaps demotivating, or something we would like to change moving forward.
5:45 PM – Sign off!
That’s it! We keep to our 8-hour workday, but we are flexible within it so that we pair together for around 6 to 7 hours per day. We believe in a sustainable pace in order to go fast forever. We don’t encourage pulling long, unsustainable hours or working beyond normal hours.
Our day is done, and I am off to a family dinner!
More resources
Tips for working remotely from Tanzu Labs
Tanzu Labs Product Manager Playbook
Tanzu Labs resources on product management
