Designing Community and Connection

This blog originally appears on the Mind the Product blog on April 2, 2020

No man (or woman) is an island. Now, more than ever, the entire world is understanding the importance of human connection and people are actively connecting with the people they know (and the people they want to know) in new and innovative ways.

We’ve been watching it happen before our eyes throughout Mind the Product APAC this week. New connections were made every day. People from opposite ends of the earth chatted online like they were sitting in adjacent rooms. As people, we don’t want that to stop. As product people, we know it doesn’t have to.

Our actions, our ideas, and our work have the ability to affect the world around us in profound ways. There is no community where this is more true than the product community.

The most important question we all need to ask ourselves today, and to keep asking going forward is: “What kind of community do I want to be a part of?” Once you’ve created a vision of what calls to you, then you need to clarify by asking “Why do I want to be a part of it?”. What will you get out of giving of your attention and time to that community, and how much do you want to give?

Communities, like Mind the Product, that allow for the free flow of ideas have enabled us to build up a global understanding of what works and what doesn’t. Let’s explore.

The Beauty of Community

Communities can be governed and shaped in different ways. They can be virtual, ad hoc, based on consistent schedules, driven by one individual or whole committees. There are absolutely no rules, so as you look to create a connection in your life, and find the right community for you, it’s always best to go back to that golden question in product management, “What problem are we trying to solve?”.

I’ve personally seen so many incredible communities built around very different ideas.

Mind the Product’s community, exclusively for product people, has grown hugely over the last 10 years. The team behind the scenes believes wholeheartedly in the strength of a diverse community, in giving lots of different voices a chance to be heard, and in enabling the sharing of ideas so that we can further the craft of product management together.

Mind the Product is the world’s largest community of passionate product people

The ResearchOps community, founded by Kate Towsey, among others, is built around the idea of deeply understanding a specific process and discussing how it can create value.

The Design for Good community allows people to connect around opportunities for tech to create social good. I’ve just formed a new members community for freelance product leaders called the Product Cooperative. My intention is that this is a small, closed community to create a sense of safe space where people can ask hard-hitting, real questions about how to build a freelance practice.

Another incredible platform is lunchclub.ai. You enter who you’re looking to meet and the platform pairs you with someone for a (now virtual) lunch. I’ve met tech lawyers, entrepreneurs, and scientists and its concept is built around network effect. I discovered it when I was invited by Product Leader, Andy Ayim. I trust Andy, so I joined!

Does Size Matter?

F. Scott Fitzgerald once said, “I love big parties, they are so intimate”.

Productive, engaging, and valuable communities come in all shapes and sizes. Members can interact and get value in a whole bunch of ways and just because a community is made up of a few thousand people, or even a few hundred thousand, doesn’t mean that you can’t create deep connections with other people within them.

Even in the biggest communities and events, you can still find pockets of conversation to join

Sometimes it’s easier to make connections in bigger communities because there’s more diversity and greater nuance to the membership. You can find pockets of conversation. You’re also exposed to a wider diversity of thought and ideas.

Occasionally though, depending on how a large community is facilitated, you might not be able to have the depth of discussion or substantial idea exchanges that a small group of people sitting around a table can have. Do you feel you are looking more for variety or depth? The answer to that will point you to large or small communities.

Virtual or In-Person

Right now, there’s no choice, all communities are currently virtual. I hypothesize that once this is all over, the value of in-person, face-to-face interactions will be felt in a whole new way. Virtual communities are wonderful because they level space and time. You can speak to anyone about anything. You can connect to individuals on the other side of the world about how they do things differently or the same.

But virtual communities often tend to be light touch, and it’s difficult to sustain attention spans. And they can be difficult spaces to facilitate and maintain the quality of content and the safety of participants. You need dedicated moderation to maintain standards – who will hold members to a code of conduct? These things hold true for in-person communities as well.  In-person communities obviously enable a deeper level of connection. You have to sense the energy and the interest of the community in a completely different way.

Virtual communities help to level space and time (Photo: Shutterstock)

Join vs Build

Sometimes in order to understand what type of community you want to be a part of, you have to start by engaging in one to see how it feels. Does it address the questions you have? Is it welcoming? Do you see yourself in others within it? Conversely, is it stretching you?

Don’t be afraid to visit a bunch of communities or meetups- visit as many as you can find in fact – because this will help you to answer the question as to whether a new one is needed.

I still remember going to my first ProductTank in London after I first moved here and didn’t know anyone – I felt I’d found what I needed at that time. I also remember the impact of hearing Kathy Sierra at Mind the Product in 2014. The ideas from her incredible talk Building Badass Users  – “you’re customers don’t want to be amazing at your product they want to be great at the context“ – remain burned into my brain to this day!

If you explore some communities and still feel there’s an opportunity to create a new space, your next step is to find others who feel the same (if you can’t find anyone, perhaps take that as a message that your idea might be too niche).

Mind the Product began when the need for it was realised. It started with a simple meetup to test the waters and from that very first ProductTank, the number kept climbing. There are now over 200 ProductTanks around the world plus five conferences. This came about as a result of one thing – that product people wanted to connect and share ideas.

ProductTank now provides a platform for amazing ideas and processes in every corner of the planet, all of which deserve the attention of the world. So, to provide an appropriate resource for this, we have amassed a library of talks and blogs in mindtheproduct.com where you can access 10 years of amazing ideas. And we know you all have more to share, our blog is always open to new submissions!

Start Today

As Mind the Product APAC comes to an end we hope it’s just the beginning of many more conversations and connections to come. And, if you don’t think you’ve found your community already, just know you’re always more than welcome in ours.

Keep talking to each other, keep sharing ideas and if submitting a blog or joining a meetup (virtual or otherwise) feel too difficult right now, or even if you’re simply unsure how to make the first move, why not start small?

Join our Slack channel where you’ll find 20,000+ product managers actively engaged every day. Watch the conversations in action and join in when you’re ready. Say hi to a fellow product person on Twitter, connect with someone on LinkedIn, or comment on a post. You’ll be amazed how quickly a support network can form.

When You Look but Don't See: Agile as Performance

While I’ve driven all of my adult life in the US, I’ve not had a UK driver’s license for the five or so years I’ve lived here. This year I decided to change all that and enrolled on an intensive driving course so I could knock it out in two weeks. Sadly after a couple of lessons, it was clear that something wasn’t clicking. I was making a lot of failing-level mistakes. (You may wonder what this has to do with product, but bear with me.)

After a few lessons, my (wonderful) instructor pulled me over and said: “I’m going to show you how you’re driving.”  He then parodied how I was cartoonishly going through the motions of checking mirrors. He showed me that I was too concerned with passing the test, and not with driving safely. I was concerned with the OUTPUT of checking mirrors, rather than the OUTCOME of not injuring anyone with my vehicle. This clicked strongly with me, and from that point forward I made safety my first priority, rather than passing the test. (I passed, by the way.)

Fast forward a few weeks to Mind the Product Singapore’s conference, and Jeff Gothelf’s brilliant keynote speech titled Lean, Agile, & Design Thinking: Principles over Process. Jeff simply and eloquently breaks down how these frameworks have become a crutch for organizations that want to look innovative, but are too scared to lean into true continuous inquiry and actually allow data and evidence into their decision-making processes. Like me with my fake mirror checks when I couldn’t have told you the color the car behind me, many product managers “perform” agile. They do stand-ups, retrospectives, and look at analytics data, but still can’t articulate their customers’ primary challenge, or describe how customer value aligns with business goals.

Simple Values of Agile and Lean

Agile and Lean were first created as a suite of very simple, very vague values that stated teams should always question the facts at hand and check whether their processes are working. The pageants of stand-up, the elaborate Kanban boards, and the lovingly crafted Post-It note walls don’t matter if no one listens to what people at stand-up are saying, or if the Kanban board doesn’t reflect reality, and your team is still only focused on cranking out features as fast as possible, regardless of whether or not you’re confident in solving customer problems.

Don’t check mirrors and miss the fact that a bike is riding next to your car, (I didn’t do that, I swear.) Ask yourself what you need to know about your customers and your team, and what you need to do to collect that info, then learn as much as you can to lower risk. That’s what Agile and Lean actually mean to teams.

Mind the Product Training has just developed a new module, only available to our corporate clients, that spells out how teams can effectively “be agile” rather than “perform agile”. Email training@mindtheproduct.com to set up an assessment call to learn more.

(I’m also happy to refer my driving instructor if anyone needs a good one.)

How am I Doing? Thoughts on Evaluating Product Managers

When you hit a certain level in your product career, a big part of your job becomes managing your team(s) rather than actually doing the work.  It’s rare that this shift is ever formally ushered in, and it’s very rare that managers of product managers are ever given formal training.

Managers of product managers or product leaders usually end up in those roles because they are great product managers, but great product managers, perhaps counter-intuitively, do not always make great people managers.   Great people managers need to be really intentional and transparent about how they manage their direct reports and what is expected from them.

Product management was a pretty young discipline when I started, and I wasn’t really managed through much of my career.  There were a few reasons for this, one of my managers was across an ocean, another was completely overstretched across 20 reports, a third didn’t come from a product background.  Whatever the reason, what I absorbed from this was that my work wasn’t that important to my manager, how I did it even less so, and finally, whatever problems I encountered, I was on my own.

This sense of isolation, of the quality of my work being cloaked in mystery, of never “really” knowing how I was performing, had serious consequences for my stress and anxiety levels.  Like most product managers, I cared passionately about my work, and I wanted to do well.  Without any guidance or insight about how I was evaluated, or where I should focus, I could only infer that I was doing well.  I kept being handed important clients, or projects, stakeholders trusted my reports, the products that I delivered performed well with customers. A strong sense of anxiety never left me, and it more often than not led to burn-out and leaving roles because I was exhausted from the guessing game and feeling undervalued.

Managing People

Without a positive example to emulate when I first started to manage people, I reflected on the management characteristics I didn’t want to emulate. One of my worst managers turned up to roughly two one-to-ones for every 10 we should have had, and that was where I wanted to start.  Of any of my meetings during a week, my one-to-ones with my direct reports are not allowed to slip.  They are your best chance of a temperature check on project health, team health, and an individual’s wellbeing.  Consistency with one-to-ones is your tool for building trust with your reports and hence your teams.

Consistency with one-to-ones is your tool for building trust (Image: Shutterstock)

From that foundation, I thought about where else I had craved direction from my managers, and it boiled down to a few simple thoughts;

1. I didn’t understand what “good” looked like

2. I didn’t know where I was on the “good” scale

3. I was never told what my manager/leadership needed from me

With these things in mind, I knew I wanted to create a feedback framework that would help my direct reports answer these questions.

A word on feedback cycles:  I think deeper feedback should be done quarterly, or at least a few times per year.  I’ve never felt like I learned that much from a yearly 360.  Extracting feedback at such a high-level meant that the same headlines surfaced again and again, and it was difficult to pinpoint where or how progress had been made.

A Framework for Skills Development

As I worked on developing my product feedback framework, I focused on two buckets of skills, Strategic and Tactical:

• Strategic skills: often referred to as “soft” skills, these skills are the most difficult to execute. They deal with communication, interpersonal skills, emotional intelligence, and organisational alignment. They help to ensure that work moves forwards efficiently and is aligned to organisational goals.

• Tactical skills: applied skills common for the facilitation and implementation of product work. These skills can and are used by any member of any team, but are crucial to the success of products and services, hence they are top priority for us.

Here are the lists of Strategic and Tactical skills that I expect product folks on my team to learn, implement and eventually master.  In my framework, I provide definitions of each, but because they can be so different in different organisations, I’ve left them out here.

Strategic: Facilitation, Process thinking, Alignment, Stakeholder Management, Inititating, Continuous improvement, Systems thing, Creative thinking

Tactical: Customer Research, Designing solutions, Planning, Tracking, Reporting, Analytics, Mapping, Experiment design

Feedback Sessions

I present this list and their definitions to my direct reports about two weeks before we have a discussion and ask them to evaluate themselves for each skill.  In my past evaluations, I was told to rate myself from 1-5 in terms of each skill, but people are not numbers and it felt really cold and calculating to rate someone.  Also, what do numbers really mean when it comes to development and progression? So I decided to use a reflection system that felt more humane and positive.  Being a learner is not a negative, and being a teacher doesn’t mean that you are ever done.   Prior to the session, you ask your report to think about where they think they are the following spectrum:

• Learner

• Implementer

• Teacher

During the feedback sessions, which take about an hour and a half, my direct reports walk me through where they place themselves, and I give my feedback on where I see them, and brainstorm stretch projects or reflection questions for as many as feel relevant.  Finally, we chat through three questions:

• Which skills are most applicable to your work for the next quarter?

• What feels risky right now?

• How can you be supported in that?

The purpose of these three questions is to help my direct reports understand that they are not expected to improve across all skills by the next quarter. Rather, I want them to be strategic and intentional about their development.  I encourage them to focus on the top three skills that will help them most with their current work.  The rest can be thought through as situations come up.  The last two questions are an opportunity for me to understand where they are worried about the work, so that I can position myself to support them better.

Generally, my philosophy as a manager is pretty simple.  I want my direct reports to know that I have their backs, that I care about their work, and I care about their mental wellbeing too, Finally, I don’t want to be the thing that anyone goes home and complains about.

I would love to hear your thoughts on how other managers help their direct reports set intentions around growth and development.  What’s worked and what hasn’t?  And please let me know if you apply any of the above framework.  I’d love to know how it went.

Want be to be a Product Leader? You Better Learn to map

This blog was first published on the Mind The Product Blog on March 9, 2020.

Mind the Product has launched a new training workshop for product managers on mapping.

I meet a lot of product people – product managers, product owners, agile coaches, scrum masters, business analysts, project managers – and I’ve learned that there are a couple of constants, whatever the title or role. Namely that each of these roles performs an ever-evolving mix of tasks and that most product people want to understand how to progress.

Why Learn to Map?

Any product manager needs to learn how to progress from the more granular task of continuous prioritization of a single backlog to the ability to assess and prioritize value and need across entire systems. For this reason Mind the Product Training has recently produced a workshop called Mapping to Solve Product Problems. What makes it different is that we teach you how to think about everything around you as a system, so you can map ANYTHING, rather than just know how to create a single type of map.

Understanding this process is often the first step product managers take to transition from focusing only on their product team to recognizing that everything they do is just a small part of an ecosystem built from overlapping systems.

There’s a progression from seeing there is a problem with your customer, to seeing there is a problem with your team’s reporting practices, and then to understanding how your organization’s decisions get made. And these are all things that a senior product manager needs to understand if they want to move up the career ladder. You can’t build a great product roadmap without the ability to map customer pain points and opportunities to your company’s business goals, and then trickle that down into epics. Any process, document, report or roadmap is built by mapping data points to decisions.

What you’ll learn

Our mapping workshop takes a look at the process of mapping from a high level. It deconstructs the elements of a map, and helps you learn how to evaluate what you need to map, how to choose a mapping framework, how to think about when to map, and the process needed to get the right data to fill out your map. When you leave the workshop you will understand that you can map anything, and you can map it in a way that gives you clarity on what to do to fix your problem or tap into value.

If you can’t start solving BIG problems for your customer, your team and your organization, then you can’t graduate up the ladder to leadership. This is why we believe that mapping is one of the most important skills for product managers to master from the beginning of their careers.

To learn more, head to our Mapping to Solve Product Problems page.

How do you Build a Qualitative Data Lake?

How do you build a data lake? In fact, what even is one? And what’s the key to understanding qualitative data operations? I’ll share my thinking on these excellent questions, and the process I’m current testing out with my own team – please feel free to share yours too!

For basically my entire 10 years working in tech, I’ve heard about companies building data-lakes. Massive repositories of terabytes of data, collected from a company’s entire portfolio of digital products, all flowing into a storage system that allows anyone with the necessary skills to “sip” from it. Building the capability of creating a quantitative data-lake is seemingly the holy-grail of technical infrastructure, and most companies in the know are chasing it. This concept of a pool of data deeper than Lake Baikal breeds visions in the head of any product person; depth and breadth of knowledge, nuance, evidence, focus, and clarity. Things we all want. Yet there is an entire range of data excluded from this particular concept of data-lakes, which often means that focus and clarity are lacking in quantitative data-lakes.

Qualitative data – collected during interviews, field research, focus groups, customer service touchpoints, sales conversations, etc. – is often data that is frittered away because it’s so difficult to collect in a way that allows you to pool it in one place. Even product teams, with careful research operations processes, architected drives, and elaborate Miro boards, have a hard time extending the value of qualitative data beyond a few months. But at least they have a PROCESS. Functional teams outside of Product often don’t have any hope of capturing the qualitative data that they collect. Perhaps it goes into a help desk black hole, or gets dropped in a Slack channel, never to be surfaced. Those countless feature requests from sales and marketing are useful nuggets and valuable data points that could build up to give REAL insights, if we could capture them.

Bad Data Habits

This complete lack of qualitative data process within functional teams often leads to really bad habits, like finding a way around the product manager, begging dev teams for favors, or throwing tantrums in a desperate attempt to get their voice inserted in the process. Product managers might complain about problematic stakeholders who “disrupt” their backlogs, but ask yourself: have you really taken the time to build a process that helps funnel this data in a way that is clear, transparent and workable? As they say in Jurassic Park, nature “finds a way” around blockers, and it’s human nature to find a way around obstacles. If folks are going around you, it’s probably because you haven’t given them a way to work with you.

What are we aiming for?

I am certainly not the first or only person to address this issue. If you’re familiar with the Research Ops (ReOps) movement, then you’ll know that a lot of it’s focus has been to make qualitative research more accessible and more valuable over the long-term. I highly recommend resources from ResearchOps.

In an email thread I have going with the founder of ReOps, Kate Towsey, I learned that she is trying to pull all her organization’s functional teams under one insight-generating umbrella, and just call it “Data Ops.” As it happens, I’ve just kicked off a similar process. Now Kate works at Atlassian (a truly massive company) and I work at a 30-person start-up, so we’re both obviously going to have to tackle this issue in different ways. Each approach will have its own character and challenges, but the outcome that I think we are both going for is roughly what I’m calling a qualitative data-lake.

What Is Qualitative Data-Lake?

Here’s the thing; I’m using this term in a way that makes sense to me, but others might have their own mental model. In this case, I see a “qualitative data-lake” as:

A process for collecting the valuable qualitative data from my organization’s functional teams, enabling us to regularly synthesize and prioritize insights, folding the top opportunities into the product roadmap, and eventually the backlog.

The other thing I want to do with this process is seamlessly blend this data stream with UX research and engineering’s understanding of effort. The data will come from wider functional teams, and will complement and be complemented by the continuous research that the product team will be conducting. This is NO SMALL TASK at any scale, and the larger your organization gets, the more complex it becomes. I’m quite lucky because the size of my organization is just large enough to make it interesting before it gets really painful.

How Do You Think About Building a Qualitative Data-Lake?

So I will start by saying that there are a lot of products out there who are trying to address this problem with integrations that hook into the help desk and salesforce, and all the other fancy things. I think that solves a part of the problem at best, and I haven’t seen any team manage to make these apps really “sing” for them, but I’d love to be proven wrong (Do you use something like this well? DM me!).

You also have to build a few steps beyond just data capture into this process – namely synthesis and prioritization points that include members of all cross-functional teams. I’m thinking about a double gate, wherein the functional teams in question come to the prioritization session after they have internally boiled up their top 3-4 points to discuss. You might be able to do this in a different way, but this is the way I’ve decided to test against.

Data Lake Process in 3 Simple Steps:

Functional teams capture data into a central repository. In this circumstance, functional teams include Marketing, Sales, and Customer Success. As we are lean, and testing out the process at the moment, we are just going to use a Typeform. They will be collecting data on:

• Customer feedback

• Feature requests

• Org initiatives that require development work

• Bugs

• Major initiative requests like new integrations

At specific time intervals, the functional teams will synthesize the data that they have collected. The product team is going to ask them to boil up the top 3-5 most important data bundles.

We will then move into a cross-functional collaborative prioritization that will include reps from each functional team.

The key steps are not the collection of the data, but the synthesis and then the prioritization of the data. The synthesis step forces the functional teams to really evaluate which items are the most important to them, and helps them discuss why. This takes a huge burden off of Product, saving us from having to do all the legwork around distilling insights from the qualitative data set.

The next step – a collaborative prioritization session – does two things. Firstly, it brings product/UX research into the conversation, which should blend, validate, and amplify functional team data points. Secondly, it allows the entire team to hear and ask questions of engineering, so that everyone is aware of how the amount of effort required for a feature will impact potential roadmap decisions.

After reading a rough draft of this, my colleague Tim mentioned that this “seems like an entire function”, and he’s right. Handling this type of process, as well as supporting ongoing customer research conducted by the product team, can eventually become an entire function. Indeed, more and more large companies are actually creating departments around Research Ops or, or potentially “Data Ops”.

What Does a Data Lake Capture?

I think the ultimate goal is to help line up two streams of insight – what functional teams are hearing through their touchpoints, and what customers are saying to the product team – so that we can clearly prioritize the most significant data patterns. And then to bring in Engineering to make it clear where the technical complexity is.

It’s meant to ensure that there is a process for all of the different things the organization hears from customers, and that requests for the product have a place to be openly evaluated and discussed. Success will mean that stakeholders aren’t forced to use back-channels or disruptive tactics to wrangle work out of the team.

How Do You Build a Data Lake?

The honest answer here is: Search me?

The slightly longer answer is that I’m trying out an incremental approach. I did an overview with a few folks from a few teams, asked how this was going now, made a process map of IS and INTENDED, and gathered a bunch of questions and feedback. I’m really lucky in that I’ve been able to pull in a colleague who will help me drive this forward. The most important thing, more important than even defining the process, is getting organizational buy-in.

This involves mapping / visualizing the processes, chatting with a few parts of the organization about the process as it stands, where they have questions. This seems like a throw-away step, but giving an overview of the process, and getting clarity on where there is friction in the current process, and where there are questions about the changes you want to introduce is actually crucial. Processes don’t work if they aren’t supported by the teams that need to input into them.

Gently but persistently nudging people towards the process is necessary, but so is quickly following up with the next steps whenever they participate, so that they know their feedback hasn’t gone somewhere to die. People will use the process if they feel they can trust it to deliver an answer. Whether the answer is yes or no is often beside the point, as long as it’s clear WHY the answer is yes or no.

Right now we are getting folks to input the data they collect from their various touch points into a Typeform. We have a synthesis session scheduled that will be more of a training than a session, and then we’ll try out prioritization. I’ll let you know how things shape up as we move through them.

The secret to transitioning to a new process? Focus, Focus, and more Focus

For the past two months, I’ve been working with a really cool start-up called GetThru. They are a progressive, political communications platform. They worked with a lot of major political platform and drove mass comms for some of the biggest campaigns in recent political cycles. Their CEO Daniel Souwiene got in touch with me because he was ushering in a new product practice and process and moving two of his employees, Toni Susi and Adam White, into Product Manager roles. GetThru had chosen the BaseCamp process framework Shape-Up as their foundation for product practice and I was hired to help Toni and Adam develop into their roles.

This has been an exciting engagement for me for a lot of reasons. The Shape-Up framework designed by Basecamp provided a really good frame for thinking about process, but also left a ton of space to adapt and fill in the blanks. This means that I was walking into a situation where the company has a shared understand of what they are shooting for, but there was a lot of flexibility and the ability to reflect and change what was needed. I hadn’t worked with the Shape-Up process specifically, but as I took a look at it, it lined up really nicely with the product practice that I have developed and used, just with different vocabulary. Shape-Up is predicated on a few ideas:

• A Pitch shaping process that gives teams times to form up pieces of work

• A betting process that creates alignment within the team on what appetite exists for pieces of work

• A loose delivery process that allowed for evidence driven development and stressed reflection

The Shape-Up process doesn’t prescribe much else besides those three components, this meant that things like customer discovery, user research, lean experiments and tests and OKRs can all be folded into it pretty seamlessly, which gave me a beautiful canvas to work with the GetThru PMs and product teams to construct a practice that worked for them.

Toni and Adam have both worked for GetThru for a few years as customer success managers, so know their customers and their product inside and out. They work on two different product tracks both of which had lots of opportunities and lots of challenges. For me, as their coach, there were a lot of different angles into approaching practice change. In order for me to quickly get a focus on where we should get started, I instituted a weekly retrospective and did a process map overview, where we took time to create a more complete hypothesis on how the shape-up process was going to work at GetThru.

The biggest challenge to the PMs working through this time was not the practice change themselves, but the overwhelm of their context. Not only were they learning the ropes of a new job while doing the job, they were educating the org on their new roles, they were working from home during a global pandemic, while also transitioning away from their previous roles. My work with them was to help them recognize that process takes time, and they can’t and shouldn’t try to boil the ocean. While there was a million things we could have started with, personas, user research, stakeholder updates, it was clear that the most important next step was to focus on delivery team process and creating transparency and alignment between devs and product. In order to get this done in time for the next cycle to start in mid-may we can to accomplish the following:

• Extract the overarching business goals for GetThru from Daniel

• Line up the potential next pieces of work, or pitches, beneath those goals

• Break down product outcomes and loose key results per pitch

• Work with the devs on a loose story map to expose complexity and risk inherent in the pitches

A dev once told me “you can’t make a baby with 9 ladies and 1 month.” This sentiment very much applies to process engineering and driving change. As much as you might want to enact change on all fronts, all at the same, that tactic usually sets you up for disaster, burn-out, or both. The best thing you can encourage and drive forward as a product person in change management is focus, focus, focus.

Are you a Builder or an Optimizer

As I’ve moved through various product roles over the last 10 years, I’ve come to realize that there are two types of product people – builders and optimizers. I fall very naturally and easily into one of these types and have found that it can be helpful to think about my own skills and career progression through the lens of theses two types for the following reasons:

• Confidence – identifying your inborn talents and strengths helps to build confidence

• Career choices – if you know what you’re naturally good at it’s easier to focus and be intentional with your career choices

• Areas for growth – identifying your strengths also pulls your growth areas into focus

The Builder Product Manager

I’m a builder. By builder I mean product people who are skilled at building products that don’t yet exist. I realized I’m a builder because all of the projects that I’ve gone absolutely wild for were projects that started from nothing. My earliest job in tech was building an app for a government agency that hadn’t yet launched. Then I went onto being a consultant where I was starting something new every three to six months. After that I went freelance where I could start with new clients often and, most recently, I leapt at the chance to build Mind the Product’s new training program.

A builder comes into a greenfield environment and gets things moving from zero to 10. If you’re just starting out as a product manager, that might not seem like a big deal, but having the energy, focus and drive to get teams moving when they are completely still is very, very difficult. It takes a certain type of person with lots of energy and a keen intuition for spotting an opportunity worthy of their energy. They are very comfortable with alignment, systems thinking, mapping, research, lean testing, and driving things forward when 99% of it is uncertain. They are very good at grasping existing systems and envisaging infinite scenarios, they have exceptional empathy and can get behind the eyes of customers to spot patterns, derive friction and opportunities. They have strong creative courage, facilitation skills, and the ability to switch context.

The main characteristic of builders is that they have the energy to build and then move a whole team from stand-still, with a lot of uncertainty and almost no constraints. It’s not for everyone, but it’s gold to builders. Builder product managers are quite common, and are often found in agencies, where they get to start something new for clients. Or they may be freelancers because they enjoy digging into new environments. Builder product managers can also be found in startups, which is where I found myself, after being a consultant and a freelancer. But at some point in a product’s or an organization’s development there will come a time where the builder’s energy isn’t well suited to the work that needs to be done. At this point an optimizer product manager is needed.

The Optimizer Product Manager

I’ve watched optimizer product managers my whole career with a sense of awe. They’re very comfortable inheriting products and taking them from one to one million. Optimizers can make lean testing sing, they can recall complex ecosystems of quantitative analytics, are adept at combing operations, logistics and product effortlessly, and are elegant prioritizers. The main characteristic of optimizers is their dogged pursuit of tiny changes that could have a huge impact. It might seem like finding a needle in a haystack to us builder product managers, but they live for it.

Optimizers cultivate deep trust with technical resources and are excellent at distilling difficult ideas into well-framed questions. They are skilled in the art of ongoing-updates and constantly shifting landscapes of data. They are happiest when they are deep in the finer details, and understand the subtle nuances of multivariate testing. You’ll find the great optimizers at larger evidence-driven companies, like Booking.com, Netflix, and Spotify.

Balance and Growth

There’s a lot of overlap in skills between builders and optimizers, but what really pushes the differentiation between them is what lights the types up, as well as what burns them out. I am never as excited as when someone says “this doesn’t exist yet”, but optimizers get really excited when they hear “we have a massive problem to unpick”. Optimizers and builders have many skills that cross pollinate, but again determining which type you are can come down what burns you out. I’ve learned so much when I’ve pushed myself into optimizer roles, but after six months or so, I tend to feel like I’m running out of gas. I know optimizers who report that their brains are often completely exhausted by the end of the day when they’re in early stages of building something from scratch.

Why is this important? Because if you don’t have clarity, you might not understand why a role does or doesn’t work for you. I’ve really enjoyed elements of the optimizer role, but I’ve always found my head was turned by builder gigs. I’ve seen optimizers in discovery struggle with the wide-open nature of the jobs, and be unable to move things ahead effectively. These skills can be developed and improved, but you have to be intentional about it.

Ops is Engineering Yourself Out of a Job

In recent years, the term Operations has been applied to everything. Design co-oped it from Dev, Research grabbed it from Design, and now Product has gotten in on the action. As per usual, there is a lot of confusion as to what constitutes “Ops.” This is a very timely question for me because after three amazing, exciting years building the Training Business and all the operations around it at Mind the Product, I’m transitioning out of my role as Director of Training Products.

More my transition later, let’s focus on the lessons I’ve learned about Operations in the 3 years that it took to build the training team from myself to a 5 person team, 80+ trainers and a global business functioning on 3 continents. As with most things to do with Product stuff, Operations, theoretically, are simple, but putting them into practice is difficult. Operations, in theory, means that thought and intention have been put into building processes so that they are clear, transparent, accessible, repeatable and scalable, by anyone that happens to be implementing them. Getting operations right has proved to be so complex that an entire global movement as risen around it, led by various factions of Design and Research thinkers.

Now, don’t get me wrong, I think these communities are really doing great work because the more Product folks understand about setting up and running operations the better, but I worry that it creates a perception that operations are a rarified skill set that only some people can do it.

As I’ve examined all of the great thinking that is going into Operations, I considered my own approach to implementing Ops. As a Builder PM, I’ve landed on Operations being the practice of trying to engineer myself out of a job. My driving question as I’m working on building a product/service is, “Are the processes and systems that I’m building going to continue to help the team and support a good process after I’m gone?” This perspective is crucial for PMs because anyone can hold a badly organized process together if they are the only ones who have to deal with it. I challenge you to reflect: if you disappeared tomorrow, would the processes you have put into place be accessible and understood by someone else? If the answer is no, then you need to rethink your approach to Ops.

*****

Lessons on Operations

Operations is a complex eco-system of tools, systems, and processes and it should take many forms depending on the project. I’m not going to outline Ops below, rather tell you the practices that I feel help me find the best operations systems for the team I’m building. If you want to check out some cool resources to get a grip on Ops in these disciplines actually entails, check out this cool visual on Research Ops from the Re+Ops community, this article on Design Ops and this blog on Product Ops from the ever-insightful Melissa Perri.

Hold a self-service mentality

From Square Zero, the thought you have to hold in your head is that everyone who currently does, or eventually will work on your team should be able to easily navigate and locate resources. One of the greatest examples of a self-service mentally is Google’s approach to customer service. For our 80+ trainers who are globally distributed, we want them to be able to get any answer they need at the drop of a hat, so we implemented a Notion, and created an arsenal of materials that helps them answer questions on content and logistics immediately.

Transparency is key

One of my biggest pet peeves is when I hear someone on my team say “I didn’t know that document existed,” or “I didn’t know we had a process for tool for that.” Transparency is created through alignment activities liking mapping, just enough documentation, and consistent communication. We have a Slack community and we share our process thoroughly, calling out when we are in a BETA stage with a new process and are uncertain about what the results will be. This creates a sense of shared endeavor. Treat people like responsible, contributing adults, and they help you create a better business.

With tooling, less is always more

Tooling, when done correctly, enables Self-Service and Transparency, but it can quickly get too heavy and garbled, and start disabling those two aims. I tend to start with a really well-organized drive system. My motto is that every document should have a home. I use a numbering system that the most important folders are on top. Generally, Drives seem to fall over when the team reaches 5+ people, but this time affords you the ability to understand the most important documents that everyone needs to access and update regularly. With this hierarchy in mind, you can invest in a tool like Notion, or a well structured Trello board to help surface both knowledge and process.

Map, re-map and then map some more

As mentioned above, I’ve found the best way to create transparency and alignment about process and operations is to map out how things work with the full-team, as it grows. Whenever a new team member joined, it was a great opportunity to do a service blueprint mapping exercise. The benefit of this is that the new team member gets an overview of the current process, and the whole team gets a view on where there are current friction and brainstorms about how to make improvements. (Learn about maps at Mapping for Product.)

Cultivate shared responsibility

Regularly mapping out processes and operations and surfacing areas of friction is an excellent way of letting your team know that they don’t have to deal with a crappy situation. At the end of a mapping session, you should have a good list of action items and they should be assigned to team members. More generally, you want to cultivate an attitude that process is never “done” and that how operations work at any given moment is only ever a test.

Reflect, reflect, reflect

I always recall an old cartoon I saw many years ago. In it, a man is trying to cut down a tree with a butter knife, and a man behind him is trying to hand him a chainsaw. The caption reads, “Stop interrupting me! Can’t you see I’m trying to cut down this tree?!” This is very like teams that are struggling with a bad process. PMs on these teams need to stop trying to cut down the tree and take the time to pick up the chainsaw. If your team is struggling, institute weekly retros immediately.

**********

I know that in a year a lot of processes that I will have instituted will have changed due to necessity. I’m not afraid of killing my darlings, and I hope that the team will do what’s right for the business on every new day. What I hope will stay behind me is the culture of constantly questioning if anything can be made better and more efficient. Luckily for me, my days at Mind the Product are not over. I will be working on different discovery projects for new opportunities that the org wants to get off the ground, additionally, I’ll be coaching on practice and helping MTP stay a product-led organization. I will also be getting back to my passion for working on developing software and with product teams. I’m so excited to understand where the practice has moved, to refresh and reapply my skills and processes to new problems and challenges.

Product Trends to Watch in 2019

Post Source

As 2019 gets underway, I’ve been enjoying taking stock of what we saw at Mind the Product Training over 2018. As a product manager I’m always looking for signals and patterns, and evaluating what early trends could mean for my products, and now for product practice. Noticing early indications of patterns of behavior can help product managers to plan ahead and work specific questions into their learning roadmaps. For my part, helpful questions to consider about any changes for any products are:

• What impact will they have on my current products, if any?

• What new opportunities could present themselves?

• Will the rise of these changes cause challenges or friction that has to be accounted for?

Recognizing Product Intuition

New for this year from Mind the Product Training is a Product Metrics workshop, and a particularly nuanced part of the program is the balance between your innate intuition and the data you collect. Great product managers often get “hunches” about aspects of their products or customers, but these hunches must be confirmed with data. The role of intuition is an ephemeral one, and difficult to quantify. At last year’s #mtpcon London in October, I was thrilled to hear Google’s Head of Hardware, Ivy Ross, talk about the role of intuition in her practice. She said: “Intuition is 35 years of extremely nuanced data, stored in the hard drive of your brain.”

This crystallized for me why intuition for product managers is not to be discounted. We immerse ourselves in our products and customers, constantly exposing ourselves to and collecting data points. Those of us with finely honed emotional intelligence and empathy skills notice small details and store them up. A hunch isn’t just a shot in the dark, it’s the coalescing of these data points into an idea. I think this year, we are going to hear a lot more about the importance of intuition and its place in product practice.

Understanding Systems Thinking

A big theme for Mind the Product Training over 2018 was stakeholder management and organizational alignment. As we worked with corporate clients, and met hundreds of product managers in our public workshops, we realized that, with product eco-systems expanding, and services connecting hardware, real-life interactions and software tools, organizations need to come together and collaborate more.

Systems thinking is the culmination of stakeholder management, and organizational alignment. It’s the acknowledgement that every department in any organization must be willing and able to collaborate with others, to recognize that information must be shared with the whole if new opportunities are to be uncovered, and reacted to if risk is going to be recognized. As product managers, we can no longer just stay in our lanes or keep our heads down. Our first order of business is to understand the ecosystems of our customers, organizations, and products, and how they all affect each other.

Mapping Methodologies

I began my journey into systems thinking as a grad student studying public policy at NYU and I’ve been on the look-out for interesting thinkers in the space ever since. Over the past few months, I’ve been lining up the pieces for the fourth full-day workshop to be offered by Mind the Product Training, entitled “Mapping for Product Managers”. The theory of systems thinking is easy enough, recognizing how pieces of complex systems impact each other, but applying the concept and extracting continual value is an entirely different story. One thinker who has grabbed my attention is Simon Wardley, whose work with mapping methodologies is exceptional. He takes the concepts and turns them around in every possible way, showing how mapping can be used to evaluate countless different scenarios. I have a hunch that we’ll be hearing from Wardley a lot in the coming year.

We’ve been doing market research for Mapping for Product Managers and it quickly emerged that mapping exercises, whether they are user journey maps, service blueprints, technical audits, or a combination therein, are among the most difficult practices in Product. How do you convey the value, align and collaborate across product teams, involve the needed resources, understand goals and intention of the maps, and keep them relevant without it being a time-suck? In spite of all those challenges, the overwhelming message from our research was “I need to do them!” Why? Because now more than ever, Product needs to understand and work towards the bigger picture.

The end of Jargon

Perhaps jargon always has been and always will be, but in the past few years I’ve seen a lot of people start calling time on silly ways to convey ideas that are actually pretty simple. In the past, product/tech teams established vocabulary to help create a shorthand that would increase understanding, but what evolved was an isolation of the teams, and subsequently the work. Check on the terms and acronyms used in your current teams: are they plain English, or do they exclude people who aren’t close to the work? Plain English, the wave of the future.

Terms that have been swirling around tech have become caricatures of themselves, and folks are getting pretty tired of having to decipher the meaning of something that should be straightforward. Instead of “We are Agile”, say “We are always learning”. Instead of “Lean Testing”, say “Let’s show that to a few customers”. Instead of “Sense Check”, say “Does this make sense to you?”. A lot of people in tech use these terms because they’re trying to obfuscate an issue or exclude people from understanding or collaboration. Don’t misunderstand me, I love a good new word, but as we think about systems thinking and necessary collaboration, our language must and should invite people in, not keep them out.

Why is it so Hard to Lean Test?: Lean Testing towards Engagement

This blog is a great boil up of some of the early lessons I learned about workshop development and creation. I’ve worked out a few frameworks to help scale this process and make it more predictable. Join me on May 20th to deep-dive into how to use product process to build your workshops.

Source Post

The Mind the Product Training curriculum is written in collaboration with dozens of expert product managers from countries and companies around the world. One the most consistent and frequent lessons that we teach in different workshops is “test early, test often”, also known as lean methodologies.

Two years ago, when I started as Director of Training Products, I knew that we wanted to create the world’s most comprehensive library of training topics for the product development lifecycle and all the skills therein, for product managers. It’s a Herculean task – which I began alone – and I began learning straight from the start.

In January 2018, we moved forward to create our third full-day workshop on the much-anticipated topic of Metrics and Analytics. However, because of the size and complexity of this topic, I rather lost the plot on the creation process. We ended up writing and then completely trashing two entire versions of the full-day workshop. This was wasteful, maddening, and completely avoidable. Luckily, we kept learning, and kept iterating, and in October 2018, rolled out our full-day workshop, titled A Product Mindset on Metrics, which received extremely positive feedback from a group of product managers at our London conference.

I’d like to reflect on the lessons we’ve learned over the past year, in the hope that these will help other product managers to identify and rejig their experimentation process.

The Process Stays the Same, no Matter What you Create

I initially lost the plot creating the Metrics workshop because I was thinking of it as something different from software, but it is still a product. It still solves a customer’s problem, it is still experienced, and its value proposition still needs to be clear. One of the most surprising things I discovered when I moved into service design is just how universal the product process is.

Start With Your Customer and Their Current Reality

We were making decisions about which new content to focus on based on customer requests and feedback, which is a good first step. However, I neglected to do a round of in-depth research about what product managers’ experience is with specific skills and how they learn them. If we had conducted that research upfront we could have saved ourselves a lot of time and tears.

Slice up the Product Into Testable Chunks

On two occasions I waited until the majority of the full-day workshop was in place before showing it to people. I didn’t have to. I could have done smaller review sessions with two or three product managers and got enough information to know if a specific module made sense and created value. It’s a fallacy to think that the whole experience has to be in place before you reveal it. Find your perforated edges and get your feedback.

Don’t be Afraid to say “This Isn’t Working”

Chucking out two versions of the workshop was not an easy choice, but carrying on blindly with content that I ultimately knew wasn’t fixable would have been worse. It’s a product manager’s job to report truth to power and to stand up for quality work. I took responsibility for not getting the research in place that would have helped us to course-correct sooner.

Fix the Process

While it came late in the game, we finally lined up the information we needed to write the workshop our audience needed. We had the courage to say “not good enough” and go back to the drawing board with the data and perspective we needed to do it right. You can also bet your boots that I will never embark on a writing project, large or small, without following the process that we developed through our mistakes.

While some people might give us side-eye for our admission that writing Metrics was tough, I think it’s beneficial to the community to admit when stuff is hard. It’s difficult to remember that we are not the user, it’s difficult to remember not to just go heads-down on something, it’s difficult to show ideas we are unsure of to critical audiences. At the end of the day, if we do not do these things, our customer’s suffer and we suffer. Mind the Product has believed for eight years that talking about the messy side of things is how we learn, and learning helps us build better products. In this case, it helps us build better product training.