Beyond the UI: How Junior Product Managers can appreciate the full depth of product development

If you're a junior or associate-level Product Manager who has ventured into the field from a product marketing, customer service, or other non-technical background, it's natural to feel a bit lost when attempting to grasp the complexity of the engineering work that brings your products to life. Cultivating an appreciation for this work is essential for fostering strong collaboration with your product development teammates and tracking the progress of your initiatives. So, let's jump in!

Take, for instance, the seemingly simple process of a user registration screen in a software product. From a user's perspective, they fill in the registration form, hit the "Sign up" button, and voilà—they're transported to their Home or Welcome screen as a new user. The entirety of the product development work that has been done to enable this simple step manifests to the user through their interactions with the interface.

But what really happens between clicking "Sign up" and landing on the Home screen?

• The registration data they've entered is transmitted...somewhere.

• The data must be checked and validated - is there already a user account with the same email address?

• If the registration data is valid, we need to create a record representing the new user and store it...somewhere.

  • Oh, and let's not forget to securely store their password—not in plain text, right? Right?

• Once we've confirmed we've got a user, we need to generate...something...that informs their web browser (in our example) that the user is authenticated and authorised to access the data associated with their Home screen (and anything else they might do while logged in).

All these steps happen behind the scenes, away from the registration form or the Home screen. It's common for software engineers to work on these components independently of the user interface that exposes the functionality, which is why it's crucial for product managers to understand the completion status of these steps.

Engineers might demonstrate the completion of such functionality by showcasing the output from their unit tests, indicating that the functionality behaves as expected under various scenarios. Alternatively, they might use a tool like Postman to simulate the registration form sending user input and receiving a response, all without having to build the actual user interface to display that interaction.

To draw an analogy, the registration form is like the steering wheel or gear shift of a car (the parts the user actually touches and interacts with), while all those other steps are akin to the engine and transmission—out of sight, but indispensable for a functioning car! As a junior PM, the more you understand the difference between the engine and the steering wheel, the better you'll become at asking the right questions, celebrating incremental progress towards completing a larger task, and honing your technical skills.

You can find me over on Mastodon at @vns@mastodon.social to continue the discussion!

From Data to Decisions: The Product Manager's Guide to Communication

As a product manager, you play a vital role in shaping the development of a product. You're the one who ensures that everyone understands and is working together towards the same goal. And while the phrase "CEO of the product" is often used to describe the role, it's important to understand that being a product manager is not just about making all the decisions - it's about making it obvious to everyone else what those decisions should be. How can you be successful at that? In short, you need to both be an effective communicator, and be confident in your judgement in the story you’re telling.

Let’s start with communication. You need to be able to convey the insights you've gathered through customer interviews, experiments, and other discovery work in a way that is understandable, actionable, and compelling. You need to be able to tell a story that takes others on the journey of what you've learned and why it's important.

While it’s sensible to keep a record of the process you’ve followed, or the methods behind the experiments you’re running, when it comes to sharing the output of your work with other people beyond the immediate product team - think designers, engineers or executives - remember to keep the key points front and centre:

• What were we trying to learn (or what question were we trying to answer)?

• Why did we think it was important to learn more in this area?

• What were the main things we learned?

By keeping a clear narrative line through those three points, it should be easier to achieve our goal of making it obvious to everyone what the next decisions must be.

So where does confidence come into the picture? Confidence, or rather, a lack of it, is one of the main headwinds you might face when trying to pin down that clear decision-making narrative. Just presenting raw data and analysis is not enough. One of my reports recently expressed surprise to me that a team member did not interpret things in the same way as they did when reviewing a spreadsheet with the data from a product usage analysis. Even though it can be tempting to share all the data and learnings when presenting your work, it’s rare for your audience to latch on to the same insights as you - everyone has their own biases and perspectives, which is why you need to emphasise what you believe to be the most important insights. Failing to do so can sometimes literally kill people! (though, thankfully, most PMs don’t tend to work in these life-or-death scenarios…)

This is the importance of confidence - you need to trust yourself and your judgment. You won't always get it right, but that's okay. Sure, Product managers have biases too, but what should hopefully set us apart is that firstly, we should be more self-aware of our own biases, and secondly, the work we do should naturally expose us to perspectives and opinions that are different. You can always change your opinion, your narrative, and your direction based on new information. What's most important is that you're clear about what you know and what you believe at any given point in time.

In short, as a product manager, you have to strive to put the most important insights on a plate for others. You need to be an effective communicator and storyteller, and you need to be open to new perspectives and opinions. You also need to trust yourself and have confidence in your judgment. By doing these things, you'll be able to guide the development of a product that meets the needs of your customers and delivers value to them and your organisation.

Asynchronous brainstorming for remote teams

Whatever product management processes and frameworks you use in your organisation, it’s very likely that at some point, you’ll need to do a round of brainstorming to come up with several ideas to address a customer pain point or need that you’ve identified. Here’s 4 tips to help you run those sessions asynchronously, without a single video call - especially useful in the context of a fully remote, distributed team! - and how you can avoid it being dominated by one or two loud voices.

Tip 1 - Set context

For a remote team, spread across multiple time zones, articulate and concise written communication is likely to be a well-developed part of your culture. For the group that you’re looking to involve in the brainstorm, make sure that you’ve briefed them in advance of when you plan to run the brainstorm. Share notes explaining the customer problem, make sure the async brainstorm process is well understood and invite questions to make sure everyone is starting from a shared understanding.

Tip 2 - Get visual and use video

Make sure that everyone draws out a visual representation of their idea or ideas. This is super important - forcing people to share their thinking visually will allow everyone to more quickly understand the ideas. Allow people to use whatever medium they are comfortable with - sketching on pen and paper, using a tablet drawing app like Concepts, a whiteboarding app like Miro, or perhaps a full-blown design tool like Sketch or Figma. You’re obviously not looking for high fidelity, you just want to minimise the barrier to participate.

Ask people to record a short video for each one of their ideas, in which they show their sketches and talk through their thinking. Using something like Loom or Slack video clips is perfect for this, though whatever tools your organisation already has in place should be fine!

NB. Make sure people record separate videos for each idea. Not only will it be easier for you to organise and revisit afterwards, but several common video clip platforms also have time limits on video length, so this minimises the risk that your participants have to rush to explain several ideas in a 3-minute clip!

Tip 3 - Scheduled sharing

It’s important to avoid ideas coalescing around whatever is shared first, so that the different perspectives that your group possess have a chance to shine through in the creativity of their own ideas. After all, there’s a reason you’re doing a brainstorm with a group, right?

Team communication app like Slack have features that allow you to schedule messages to send at a later time, rather than immediately. When briefing your group, explain how to use the scheduled message feature in your team’s communications app, and set a time for sharing the first round of idea videos. Make sure you account for different time zones, and give everyone enough time to fit some idea generation into some point during their working day l. As an example, in my team, giving everyone 24 hours after sharing the brief feels like the right schedule. By doing this, you’ll also have a great moment to look forward to as the videos start rolling in and you can see what people have been up to! 

Tip 4 - Do multiple rounds

Research shows that people’s first ideas do not tend to be their best ideas. Once everyone has had a chance to see the first round of ideas, it’s extremely likely that they’ll be inspired to come up with something even better - either a variation of their original idea, or something that builds on something else they’ve seen.

Once the first round of idea videos have been shared, remind your group of this and that you’re not yet at the point of eliminating ideas from consideration. Give people a chance to watch the videos, ask clarification questions, and set another deadline to schedule another round of idea videos.

You can repeat the process as often as you think is reasonable, based on how many people are in your group, how spread out you are, and how well the first two rounds go. If you are all in similar time zones, then you might have time to squeeze in more than two rounds. If there are 8 hours or more of time difference between people, you’ll probably have to give a full day for each round and therefore run fewer rounds. 

Wrap up

Hope this helps you and your team migrate your team brainstorming workflows to a more remote-friendly, asynchronous process, whilst still achieving effective results. Hit me up on Twitter with any questions / comments on this post, to chat product or just say hi!

Running an Experience Map workshop

If you work in product, you should be reading Teresa Torres’ “Continuous Discovery Habits”. I’ve recently had the opportunity to put some of the theory from the book into action by creating an Experience Map at my new company, GooseChase, with a group of people who have never created an Experience Map before. If you’re in a similar situation, here are my tips on how we made our session successful and how it fed into the subsequent foundations of our continuous discovery process.

Sidebar - some background on GooseChase - we have built a platform for organisations like companies, schools or non-profits to create scavenger-hunt-inspired experiences for their teams or communities. Our customers use the platform to create a wide variety of experiences, from classroom learning activities to employee onboarding, team building or fundraising events.

What’s an experience map?

This post will make much more sense if you’ve already familiarised with the key concepts of Teresa’s Continuous Discovery framework, but just to recap, experience Maps are shorthand visual representations of a customer journey, that allows somebody to easily digest what a customer is going through without having to read walls of text! Why drawing maps helps sharpen thinking

What we were trying to do

As Head of Product, I wanted to run a remote workshop to create our first experience map - the other participants would be our Head of Design, CTO and CEO (who had the main day-to-day oversight of Product before I joined). The goal was to produce an experience map, relevant to our product outcome, that could help inform our Opportunity-Solution-Tree and provide a baseline visual for our customer journey that could be shared more widely across the team. 

Preparing for the workshop

There were a few key pieces of preparation that helped make our workshop a success. The most important one was identifying a product outcome with the other participants that we felt supported our current primary business goal. For GooseChase, our current business goal is to improve subscriber retention and reduce churn. Our best subscribing customers are the ones that have multiple people in their organisation using our platform to create experiences more frequently. For that reason, we settled on a product outcome of increasing the average number of experiences created by our subscribing customers. 

With the product outcome documented, I then spent some time alone, thinking about an appropriate constraint for our experience map that would help make the workshop run more smoothly. Too broad a constraint might make it hard for the group to start working on a blank canvas. Too tight a constraint and we may not visualise all the stages of the customer journey that would be beneficial. I ended up settling on a framing constraint for the experience map workshop of “How do our subscribing customers create experiences for their communities?” I wanted our group to consider the stages that our customers went through in imagining an experience they wanted to create, and how they would go about achieving that, including the touchpoint where our platform may or may not factor in to their thinking. We want our customers to understand where they could use GooseChase for use cases they maybe haven’t previously considered, so this constraint felt appropriate. 

With a constraint set, I spent some time creating my own individual experience map. This gave me the opportunity to figure out the best tooling for the workshop and how best to put the theory in to practise. I realised that when assembling your experience map, there are two common approaches you could take:

1. Do it chronologically - it's sometimes easier to just start at the beginning of the journey and create visuals for each step.

2. Focus on key moments - however, it's often easier to picture what the key moments are, start with visualising those and then fill out the rest of the steps on either side.

The last bit of preparation I did was to use Miro to set up a board that I could use to run the workshop. I created some example visuals and left a set of components ready to copy and paste to assemble our map.

The only preparation the other participants had done in advance of the workshop was to read up to and including Chapter 4 of Continuous Discovery Habits, so they were already primed with the key concepts.

During the workshop  

The workshop ran pretty smoothly. We only had a 90 minute slot available to us, but made use of it pretty well! We used Zoom for the video conferencing and as described before, Miro for the actual mapping. This is what we worked through:

• Recapping context of the product outcome we are shooting for + some key passages about experience maps from the book that I’d highlighted in my initial read through. This took about 10-15 minutes.

• Work through an experience map example as a group that had nothing to do with GooseChase. I facilitated this - I had chosen an example of “Making your way home after a night out with friends”. We went round the group, suggesting key points to visualise on our example map. The initial ideas were all to do with the early part of the journey, essentially how someone would decide what method of transport to take home. To constrain this example map to make it more meaningful in the time we had, I asked the group to assume that a ride-sharing app of some sort was chosen as the mode of transport. From there, the group came up with several great steps of the journey, from deciding which app and who was going to pay, locating the right car on arrival, to checking in with friends to let them know they’d arrived home safe. As we were coming up with these steps, I was throwing together arrows, speech/thought bubbles and little avatars of people, cars and phones to create the steps of our map. You can see the result below! This part of the workshop took about 20 minutes.

View fullsize

Our quick and dirty worked example of an experience map

• After this, I asked each person to make a copy of the Miro board, and split each person into their own breakout room on Zoom so they could start working on their version of the GooseChase experience map. We did this for about 30-40 mins - during this time, I was rotating between the different breakout rooms, offering any tips or advice based on my own experience of drawing my first map. Thankfully, no one was really stuck and everyone brought their own perspective and lens to creating their individual experience maps.

• I then brought everyone back together for the last 20-25 mins to start building our shared map. I copied everyone’s individual maps (including my own!) back into the shared Miro board, and asked each person to spend a few minutes talking through their own one, what they had done and the approach/mindset they had. It was really useful to see and hear each person’s thinking and have a chance to ask questions. One of the participants had written short labels to describe each stage of their experience map, which actually made the final part of the workshop very straightforward. We copied all the ‘stage’ labels from that person’s map into a list, and spent the remainder of the session as a group going through the other maps and labelling the stages. If we found a visual in someone’s map that couldn’t already be described by a label in our list, we would create a new label and add it to our list. This was the easiest way we found to identify all the unique stages across all our maps. We ended the session by dragging out all the labels from our list into a chronological journey, but ran out of time when it came to adding visuals to the map.

After the workshop

I did the first draft of adopting visuals from everyone’s individual maps into the shared experience map, filling in each of the stages that we’d identified with our labels. Once I’d done the first draft, the rest of the workshop participants made their own edits/amendments to settle on our v1. This took part asynchronously in the next couple of days after the workshop ended. 

Finally, the ‘stage’ labels that we’d identified ended up serving another important purpose - when building out our Opportunity-Solution-Tree (the next piece of foundational work we did), those labels acted as the top-level opportunities in our tree. We just had to rewrite the labels to frame them as opportunities from a customer perspective. 

Wrap up

I was really happy with what we achieved as a group in the 90 minutes we had - everyone had got a lot more comfortable with drawing out experience maps, worked through some examples and we’d built out the bones of our shared experience map. The output allowed us to quickly progress through creating the shared map and move on to the next parts of implementing our continuous discovery process. 

I hope this post helps provide some actionable advice and suggestions to you and your own teams as you work towards becoming more effective product teams. Teresa herself is far more experienced and smarter than I am in these matters - you should definitely give her a follow if you haven’t already. You can also hit me up on Twitter with any questions / comments on this post, to chat product or just say hi!