Product Owner vs Product Manager: Worry About Outcomes not Titles

Source Post

Over the past year I’ve worked with hundreds of product managers in dozens of companies, and there’s been one question that has sounded like a persistent drum beat: “What is the difference between the role of a product owner and a product manager?”.

When confronted with this question, I used to hesitate, because from company to company there are a million things that can affect the roles; the product, larger organization structure, product development process, cultural differences, regional differences in commonly-used titles, the list goes on.

On the advice of my colleague Martin Eriksson, I now turn the question around on the questioner, and put forward two questions for them to consider, namely: “What are you trying to fix?”, and/or “What outcomes are you looking to achieve?”. It makes sense that before you look to impose a new or different role, you should have a clear understanding of what’s happening now.

At a high level, there are two buckets of work. The first is to set the strategic vision and continual alignment of the product with the rest of the organization. The second bucket is implementing, tracking, and reporting back on progress. In my experience, one role handles elements of both of these buckets. In Scrum that person is called the product owner. In Agile that person is called the product manager. In general, when referring to these responsibilities the two roles are completely interchangeable.

Complexity is introduced when organizations add a layer of hierarchical oversight, aka the layer that is ultimately responsible for making decisions about the product vision. When I worked at Pivotal Labs, an Agile shop, we referred to our client sponsor as the product owner. They could also be referred to as the business owner or more generally the key stakeholder. In organizations that implement Scrum, this becomes muddied because the product owner runs the backlog, but isn’t empowered with a final say, so a product manager gets slotted in. You see the rub?

Mind the Product Training is currently working on a project that illustrates this point. Despite the fact that I’ve been a digital product manager for the past eight years, I’m not a product manager at Mind The Product – I’m the Director of Training Products. My main remit is service design for our training programs. Yet, there are several digital products that Training needs in order for the service to function properly and I don’t have time to manage those projects and deliver our service.

Enter Christopher Massey, Mind The Product’s Product Manager (so meta). He is responsible for the planning and delivery of all of Mind the Product’s digital products, including our website and admin tools. Our training program is past its testing phase, and we can now turn our attention to honing our digital interactions and touch points. So I called for a meeting with product (Chris), marketing (the brilliant Amy Roberts) and myself. We came out with a nice plan for moving forward with our needed training pages. Chris will be the product manager, and I will be the product owner.

So let’s unpack this a bit. Why is Chris the product manager in this scenario? Simply put, it’s his current title, but more closely, he will be managing the breakdown of vision into workable stories, and will ensure that the delivery team understands intention, value, and priority. Chris will manage the “how” of the product. My role as product owner will be to hold the training goals and vision so that the digital products can be appropriately guided. I will own the “why” of the product because I’ve spent the past 12 months figuring it out. At other times, for other products, Chris will actually wear both of those hats because he will have done the work to create the product vision, and he is empowered by Mind the Product to do so. In those cases, there is no need for a product owner.

My point in presenting this scenario is that the titles are not as important as understanding the outcomes that you would like to achieve, and the weaknesses in your current structure and process.

Here are some questions that you could take to your team, not necessarily to impose a new or different role, but to understand whether your product role is appropriately empowered and supported to deliver the product.

• Who is currently doing what right now?

• What are you trying to fix first? Second?

• What are the main challenges of the key players?

• Who holds information you need?

• Do you feel you have clear access to the information you need?

• What is your process for making decisions?

• Is there clarity around current process? Is ownership clear? Are your people empowered?

• Is alignment and reporting an issue? Why?

• What does success look like?

If you gather answers to these questions via one-to-one interviews with relevant parties, you will at least come up with a better understanding of what’s happening in your team. Next, I would recommend a collaborative retrospective framed around improving process, focused on creating action items with assigned responsibility to individuals. This would then become your “beta test” for changing roles.

I’d like to hear from you. Do you have product owners? Product managers? How does it work for you?

Mirroring Product: a Breakdown of Process

Source Post

For the past year, as Director of Training Products for Mind the Product, I’ve been creating a training platform and service. During this time I’ve worked with dozens of companies and hundreds of product managers; hearing about their challenges, and working with them to set game plans for shifting practices.

The one theme that has come out of working with these clients is that other departments in a company could work better with the product team/s. In my musings on how to address this issue, two tactics have emerged; the creation of understanding, and building a roadmap towards complementary practices.

So, how can departments who are not building software “mirror” the approach of product teams? By viewing their outputs as products, and taking the same approach to evaluation, communication and optimisation as best-practice product teams. Until my current job, my products were all software projects, so it was an eye-opener for me that, even though I’ve shifted to building a service model, nothing about the process I run has materially changed.

I’ve managed to shuffle the myriad of Mind the Product activities into four buckets in order to break down the process into pieces that other departments can mirror:

Align Around Goals

Product teams understand that in order to explore a complex and changeable domain, clear goals are a rock-solid requirement. This includes top-level goals that define a clear vision, but also more detailed goals that help teams to understand how they should measure their day-to-day outcomes.

Test Everything

I believe that once “testing goggles” have been acquired, they cannot be let go. Once a team understands that, each action they take is then a hypothesis, and outcomes either validate or invalidate what was understood about the product. At MTP this means that we structure all our activities as hypotheses, for example, “We bet that sending materials ahead of time will impact participant engagement,” and then we measure the results.

Take Stock Regularly

If a team is always testing and therefore always learning, then the distillation of what has been learned must be fed back into the product at regular intervals. For every major activity or milestone that MTP Training experiences, we have a retro with the team involved, evaluating what went well or what didn’t go well.

Bake in Continuous Improvement

Just reviewing the good and bad is not enough. Teams must also create and address activities that might cause improvements. Retros should culminate in a list of action items that are meant to alleviate past friction. An organisational culture of openness and transparency is needed in order to enable continuous improvement, but you can get started by scheduling retros consistently, and following through on the action items they surface.

I’ve seen bakeries and law firms espouse these concepts. In general, if an organisation can drive for general adoption of these processes, then not only will departments work more effectively with product teams, but they’ll generally work better.

Taking Stock and Planning for Impact

Source Post

For better or worse, the turning of a calendar year conveniently provides us with an opportunity for introspection. This time of year, we examine what we have accomplished, how we feel about it, what we want to do, what we dream of doing, and what our goals are for the coming year. Sadly for us all, this kind of attention is often only lavished on taking yoga classes or learning the ukulele, albeit worthy goals, but it is never applied to our careers.

Maybe we don’t often make resolutions for work because it’s too much to think about, and too much feels outside our control. In myself I’ve found that to be a bit of a cop-out. So this year I thought I would make a framework to help kick-start my thoughts. Sometimes simple guidelines are the best for spotting patterns and insights. I’m putting the framework up here because, in my job, I get asked a lot about skills development and career development and maybe others will find it useful. I did this specifically about goals I have for my job, but others could do it for career goals in general, or personal + professional growth.

I found it helpful to write each answer on post-its with a sharpie (am I product person or what?). I do a pretty massive brain dump for each category and see what emerges but some folks like to focus on fewer answers and give a lot of context. Whatever works for you. Also, the order, with the goals coming last, is not an accident. The preceding questions should inform your goals.

I also don’t think you need to answer all of these questions. You can pick the ones that mean the most to you. But I encourage you to answer the two categories of goals below.

• Write down the things you feel were accomplishments this year

• Write down what felt challenging about this year

• Write down the things you think you should stop doing

• Write down the things you think you should start doing

• Write down times when you needed to ask for help

• Write down your goals for the next year

• Write down your goals for the next five years

• Combine the goals stacks

Once you have your cluster of goals, you can do two things. You can stack rank your goals in order of importance to you, or you could be even nerdier and do a 2×2, with effort vs. value, or whatever labels you want, placing your notes on the grid.

Then take note of a few things. Do your short-term goals rank higher than your long-term goals, or vice versa? How much effort would be needed to move these things forward? Do you have a ton of goals or not many? How many goals do you feel you can realistically accomplish?

Finally, try writing down action items you could do this week or next to start putting those goals in motion. The very first steps you could take, small ones, a conversation, a phone call, research training or workshops. (Hey, Mind the Product can help with that training!)

Making a concerted effort to think about what you want to accomplish with your job or your life has zero down side. What are your goals for 2018? Make 2018 the year you make something happen.

How we Grow as Product Managers

Source Post

It starts local. A friend asks you to come to a meet-up, or to have a beer with a few friends from Silicon…(Valley, Alley, Roundabout, Beach, insert your fave here). Or you set up a coffee with a cool product manager or designer you know. They tell you about some books to read.

Then you head to a conference where you see 1500 other product managers from all over the world. You hear their stories and laugh about sharing the same problems.

You apply for a job in another country, you want to see how they do things in California. You come back after a few years looking forward to seeing what’s changed in your home city. You build your library and your toolkit. You continue to build stuff, some things that you’re proud of, other things that frustrate you.

The career (and job) of a product manager is one of finding commonalities, patterns and lessons. The stories that we hear from product leaders from around the world is that diversity of perspective and experience are what drive us to build better things and be better managers. Our world continues to shrink, and change continues to happen faster than ever. Getting an edge means collecting as many valuable experiences as you can from as many places as possible.

Mind the Product Training

Eight months ago Mind the Product mapped this journey as we considered how to build our new training program. We knew we wanted to create a best-in-class training program that would embody the seven years of lessons we had collected from our conferences and meet-ups. We knew the only way to get there would be to test out a lot of different assumptions we had about what could work and what’s needed. Our mission is to make Mind the Product’s trainings one of your most valuable experiences. What’s happened since then has been nothing less than the coolest thing I’ve ever done:

• Mind the Product has done public trainings in five countries reaching hundreds of product managers

• We’ve trained a dozen trainers with a dozen more on deck to join us, in four countries across two continents

• Myself and a small cohort of expert product managers have written nearly 24 brand new curriculum modules and are currently writing another six

• The core team has iterated on a corporate sales process that assesses need and can quickly adapt to unique challenges and scenarios

• Finally, we’ve worked with a half-dozen corporate clients and designed custom curriculums for their teams, with a crazy sales pipeline bubbling for 2018 Mind the Product Training

What did we learn?

So. what did we learn? We could write a book (and are planning to) but the most important lessons that we learned are the same ones that Mind the Product teaches in our courses:

You don’t KNOW until you’ve done it

We will never be finished: our training service is always expected to change and evolve, so we’ve baked iteration into the process

Your customer is a font of knowledge: we will always ask you about your experiences, and get feedback on how you felt going through our trainings

At the end of January, Mind the Product is launching its first multi-city training, taking place in four cities over the course of three days. After that, we’ll be rolling on more cities in the following months. Our vision is to have dozens of trainings happening concurrently in cities around the globe, while also being able to maintain the most current content, combined with the best instruction given by experienced product managers.

Watch this space, if we keep moving as quickly as all this, we’ll be in your city faster than you can groom your backlog.

To see where we’ll be first, and to book your place for the next part of your journey, check out our public workshop calendar, or request more infomation about company training.

How Curious: Mindset of a Product Manager

Source Post

Being a product manager encompasses many things; vision, organization, analysis, and communication, to name a few. But in my experience there is one universal trait that permeates almost everything a product manager does – curiosity. In the context of product management, I see curiosity as a desire to fully understand a problem from all angles, to want to gather information from a diverse range of sources, and additionally to understand how outcomes would have an impact on success.

I’ve noticed the product community has been talking about this curiosity mindset, or learning mindset, or testing mindset with greater frequency in the past few years. Lauren Gilchrist’s talk on “How to be a Scientist”and Erika Mule’s work from “Just Enough Research,” have both helped embed the concept of learning as a core skill of product teams. This understanding about a problem inquiry and curiosity needs to be seen as a key component of the product manager role.

I’ve been thinking a lot about how to approach learning as I write the Mind the Product training curriculum. Each phase of the product development lifecycle requires a slightly different type of learning mindset. Being a scientist is necessary when you’re in heavy prototyping mode, but when you’re approaching greenfield products, you need to be more expansive. Likewise when one is driving towards a release, you have to become hyper-intent on risk, and testing is not as useful.

The more I thought about it, there seemed to be three emergent mindsets that help product managers think about being curious.

These three seem best used at certain times during development, but like most things there are no clean lines between them, more of a fluid shift. Some take top priority at certain points and then move over more strongly into another circle. We are well served by Venn diagrams here at MTP, so let’s use one.

So what characterizes these mindsets? Generally the main difference between them is the scope of view that a product manager takes. They are all geared to reacting and adjusting to new information, but there are different sizes of vision occurring.

The Explorer

It shouldn’t surprise many people that the Explorer mindset comes into play most strongly in the discovery phrase of the product lifecycle. I thought of explorers of the old school, who were blazing a trail for equal parts science and glory. They were well-equipped, they carefully thought about the skills they would need on their exploration. They had a rough idea of what they wanted to accomplish. Their mission was to set the frame of the map and perhaps make some valuable discoveries that made people pay attention. Explorers set their eyes on the horizon, but are also constantly watching for signs of risk and danger.

When you’re not quite sure what you want to build but you have a hunch that there is a pretty big problem to be solved, you’ve stepped into this mindset. You are using your past experience and your intuition to start pointing you in a direction, and you’re meticulously gathering and cataloging data from all sources. Explorers map the terrain, take detailed samples of the environment, and try to get to know the locals. Product managers are framing your business case, analyzing macro-data and talking to potential customers.

Most importantly, this is the time to really reach big and figure out the potential of the idea. You don’t find treasure if you don’t search for it.

The Scientist

As the problem has becomes more and more defined, the scientist mindset makes its appearance. Once you’ve identified and properly assessed a problem as an explorer, you can begin to think about possible solutions. This is where product managers begin making bets with themselves, creating hypotheses as to what success looks like, and seeing how concepts perform against that. Solutions, concepts and features are tried and discarded at this point if they are found to not work. The scope begins to narrow and focus.

Product managers start working intensely with various fidelity prototypes, or find ways to visualize ideas for testing with the least up-front investment. Risk comes more into play as the team pays attention to the details of the experience, like usability, tone and process.

It’s also important to debrief and take stock of the findings, in order to make appropriate changes and adjustments as you move into subsequent tests.

The Driver

Eventually, the answers become clearer and the experience firms up. You want to get something out the door as quickly as possible, this is not the time for being expansive, this is the focused mindset that is needed in order to push out a release. Yet despite this focus you don’t stop paying attention to incoming information and keeping an eye for unexpected obstacles.

even when you’re headed to uncertain destination, drivers still have to make constant adjustments and pay attention to the route that you’ve set forth. If a major roadblock came up, you would reroute, calculate the amount of time lost and report out on a new ETA.

The Driver mindset is about maximizing efficiency and minimizing risk on your way to the destination. Each time you do it, you improve your understanding about the process and can cycle through it faster and better.

As I stated above, these mindsets are not completely disparate. Often you have to find yourself in two learning mindsets, especially if you are doing dual track development. In my experience, a clear characteristic of a senior product manager is someone who understands which mindset is needed for a particular problem. This is not an understanding that can be achieved overnight, but it can be useful to understand these subtle shifts as you move through your career as a product manager.

Do let me know what you think. Do these mindsets apply to your work?

What’s the Biggest Challenge for Product Managers?

Post Source

For the past two months, I’ve been conducting research and discovery to help establish some ground rules for the Mind the Product Training Program. As an organization we’ve set some goals for what we want to accomplish with our training. These are:

• To offer the same best in class experience that our Mind the Product conference attendees get when they come to our events.

• To serve our core MTP audience of experienced product managers who want to continue to grow their already in-depth skill sets.

• To bring our training to as many of our Product Tank communities as possible.

• To impart lessons that product managers can apply immediately in their jobs.

So with all this in mind, I’ve been looking at and collecting data which inform how we achieve these goals.

Tell me What you Want

But, having analyzed the data, I’ve found that what product managers say they want differs quite a lot from what they state they need. What do I mean by this? The training subjects that product managers list as those they are most interested in do not line up with the areas where they say have the greatest challenges.

Mind the Product sent out a survey to its community in 2016 and 1,200 product managers from five continents responded. I randomly selected 350 responses and analyzed the responses to the following two questions:

What do you feel your biggest challenge as product manager is?

What topics are you most interested in learning about?

Stakeholder communication was the biggest challenge – by 12%. But this answer took many forms, some respondents simply stated stakeholder communication or stakeholder management. Others called it “problems with alignment”, “difficulty getting buy-in from higher-ups”, “keeping all the teams on the page”.

So I expected to see training on communication, alignment and presentation skills rise to the top of desired skills list, based on this data. But the most requested training topics were user research, conducting user interviews and metrics and KPIs.

Obstacles and Takeaways

So let’s state the takeaway that we can draw from these two pieces of data: product managers are most interested in understanding how to improve and optimize their products, but reporting out and discussing their work with the wider organization creates obstacles.

This quantitative analysis helped me to formulate an interview script that I used in the qualitative research round that followed. When do our product managers feel they encounter the most difficulty in communication? Where do they feel most confident in their own work? How do they currently work with their greater organizations? How do they work with their teams? Where do they feel they miss the most opportunities to improve their products, why?

I can’t give away the store, but following these two rounds of research and analysis, the main takeaway is that any conversations around specific and tangible skills should and must be coupled with lessons about the value of the work, how to explain it, and how to report out about it.

Do you agree? What’s your biggest challenge as a product manager? How does it line up with the skills you are most interested in learning? I look forward to hearing from you.

The Six Essential Books that Every Product Manager Should Read

Source Post

I always tell the participants of my workshops that as a Product Manager you should be voraciously curious about what’s happening in the field. Read books, keep tabs on blogs, follow people on Twitter, listen to podcasts, be a massive consumer of ideas and then see what resonates most with you.

Here are some of the first books I read after getting into product management. They are also the books that I keep with me wherever I am, and I return to each of them every few months or years. These books capture fundamental theory as well as basic practices. I have written in the margins of my copies and the pages are dog-eared, but I still use them and regularly quote from them. The ideas in them remain as relevant today as the day they were published, and the practices just as useful.

I recommend this list as a great starting point for new Product Managers, or for anyone who feels they need support with tough problems.

The Inmates are Running the Asylum: Why High Tech Products are Driving us Crazy and How to Restore the Sanity

by Alan Cooper

With chapters titled What Do You Get When you Cross a Computer with an Airplane? and Techno Rage, you can be assured that Cooper’s book will not bore you. Published in March 2004, Inmates was one of the first books published that strongly called out the the insane usability problems with most software tools at the time. Using the phrase “Dancing Bear-ware”, Cooper lambasted the technology community for the idiotic way in which software was built, calling out isolated software development teams in general, and Microsoft specifically, for first ignoring their user and then blaming them for “not getting it”. It was the first time I had heard cognitive friction discussed in relation to software, and it is something I’ve always kept front and center when building products. The final section of the book is both a brilliant and specific treatise on the need for interactive design and how “polite” software should be the goal of every product team. Yet, 14 years later, I continue to run into the same type of thinking that Cooper condemns in his book. Relevant, applicable, and funny, I regularly name Inmates as the first book any product team member should read to understand what we’re trying to accomplish and why.

As a bonus the book is now available online for free.

Inspired

by Marty Cagan

Ah, Inspired. Like a cool breeze on a hot day, this seminal work by Marty Cagan from Silicon Valley Product Group is an easy-to-read primer on the role of a modern Product Manager. Published in 2008, Cagan continues Cooper’s work by instructing his readers to focus on their customer’s misery, rather than technical solutions. I loved this book because Cagan is really specific about the traits that he believes Product Managers should have, including leading by objective, the art of wandering around, and having empathy, for your teammates and customers. When you’re reading the book Cagan’s passion for his work and great products is palpable and infectious. Since reading the book, I’ve aspired to become the kind of Product Manager that Cagan would be proud of.

XP Explained

by Kent Beck

I spent a few years working as a consulting Product Manager at Pivotal Labs. My favorite thing about working there was a mandate to “do the right thing”. What “doing the right thing” at Pivotal Labs means is captured by Kent Beck in XP Explained. XP stands for Extreme Programming, which is another way to think about agile development. I believe that if XP explained were compulsory reading the world would be a kinder, more efficient place. Beck explains XP values, principles and processes in simple, understandable terms and gives examples of teams that benefited from using them. The main takeaway for me has always been that a culture of collaboration and openness breeds the ability to improve because team members can talk about what is going on frankly and in real time. Creating this type of culture is both easier and more difficult than it seems, but Beck breaks it down into actionable processes. I always want to work with XP teams.

The Hard Thing about Hard Things

by Ben Horowitz

The story of Horowitz’ rollercoaster ride at the helm of Loudcloud and Opsware is a fun read, but it’s the lessons he imparts that make it part of this list. He talks candidly about some of the mistakes he made, the traits he looks for in people he hires, how he empowers his teams. Product Managers, no matter how junior or senior, should always lead by example. Reading Horowitz’s story taught me a lot about how to think about the soft skills that are beneficial to the role. He also has written one of the best paragraphs on the Product Manager’s role. At one point, I actually wrote it down word for word and taped it next to my desk, but I’m not obsessed or anything.

The Lean Startup

by Eric Ries

The book that launched 1,000 experiments. Actually you could easily estimate that The Lean Startup is responsible for launching millions of experiments. It was this book that cemented the concept of “assumptions” and “validations” in modern product development. When Lean is paired with the practices described in XP Explained and Inmates, you have a very powerful pathway to building the right thing very well.

The User Experience Team of One: A Research and Design Survival Guide

by Leah Buley

I found this book when I left the safe haven of teams and was forging a path as a freelancer and independent consultant. For the first time I was working alone and I needed some support. Buly’s book does an excellent job of articulating both the goals and progression of UX research and design activities. Each chapter outlines the lifecycle phase, what is typically needed during that time, and the activities you could consider implementing for specific outcomes. Each activity listed comes with descriptions of the prep time needed, suggested agendas, the goals, the materials needed, how to handle remote situations, and what to do next with the things you learned. I often refer to it when I need a refresher on how to conduct specific activities and how to articulate why we’re doing something to my teams. Everyone, no matter what point of their career they are in, needs some support.

Stakeholders Should Participate in Discovery and Framing.

What is Discovery? What is Framing? Questions that you will often get from stakeholders who are new to UX practices, or new to software altogether. Both refer to periods of time in your product development lifecycle that happen at the beginning, or at heavy change points for your product. D+F sprints ensure a crystal clear understanding of what the problem is, and who you are trying to solve it for. I’ve found budgeting a few sprints for Discovery and Framing can help answer crucial design questions, help focus your backlog, and create a chain of priorities. This blog isn’t about the machinations of D+F, if you want a great read that gets really specific about design sprints, check out Sprint by Jack Knapp.  This blog covers the oft-overlooked need to ensure that the primary stakeholders for your product within the organization are involved in D+F activities and collaborate on the developing vision.

Stakeholder involvement in Discovery and Framing are flip sides of the same coin. Heads: missing out on crucial knowledge and perspective, and Tails: knowing that you have buy-in from people whose support you need. Involvement could take a lot of forms, but some of the most important touch-points include:

• Getting major stakeholders in the same room to frame a shared definition of the problem and discovering what needs current customers have at the user interface.

• Listening to at least two user interviews, usually in the first and last rounds.

• Participating in some form of a synthesis exercise.

• Helping line up insights as they apply to overall goals.

• Participating in a design studio.

• Attending a meeting that summarizes insights and discusses implications on product.

• Including individuals who could pull the plug on your work. If that’s all of them, then you’re going to need a bigger boat.

Build Strength on Strength

Let’s start with the fact that your Stakeholders have expert level knowledge about important parts of your organization. If they don’t participate your team loses the benefit of that knowledge. These folks set strategy, process and policy, and their reports will interact with the product or the product output. Their regular participation means that PMs don’t have to hold all of that knowledge in their head, and can offer perspective that will ensure solutions work for everyone. It is a good idea to solidly understand which stakeholders are necessary for the success of the product, and then get up to speed on what those folks are trying to accomplish that could benefit or affect your product. (See Stakeholder Interviews.)

Why do you Need to Talk to Them?

The other big reason is a quote that every PM has heard at least one time or another: “I can just tell you what we need to build.” Unless the stakeholders who are skeptical of user driven practices listen to users and help draw out insights, then a PM can find themselves in an opinion fight, which completely defeats the purpose of research in the first place. Their presence in D+F also means that they are hearing from their customers first hand. This is information that they cannot argue with. With their participation, it transforms into an agreed upon understanding of what your customers feel and think about the experience. Instead of arguing about what the problem the is, you can discuss the implications of that problem, and that’s a much more productive conversation to be having.

Ultimately having your stakeholders participating in the D+F activities means that you are all using joint strength to move the project forward to the same destination. If you don’t have your stakeholders with you on the journey, when you arrive at your destination, you risk turning around and seeing your stakeholders scattered all over the map, demanding the project head over to them. 

Silence is not a Yes

It’s pretty common. Other folks in your organization have full-time jobs, their schedules are typically quite packed. There isn’t a lot of understanding about why they need to be involved in this work. Often when you invite stakeholders to research or synthesis, you are met with an “I’m unavailable,” or just silence. It is always possible to assume that this means that as a PM you have carte blanche from these folks to do this work, and that at the end of D+F your vision will be the one accepted. I have found myself in this circumstance a few times. I have learned the hard way that silence does not equal buy-in.

Some organizations do have deep enough roots in lean and agile processes that PM’s are endowed with the privilege of the green light to “research and build.” The remainder, (which is the majority,) should not assume that a lack of attention means that their stakeholders will be fine with the problem definition and product vision presented. I’ve gotten to the end of extensive research periods and been caught totally off-guard that a major stakeholder is skeptical of the findings and advocating for a different vision. Participation and collaboration of stakeholders from D+F inception means that a PM can unearth disagreements and misalignments early and often. Typically, this results in a clear pathway forward to building.

Often, there it is an uphill battle getting the needed people in the room for these activities. It helps to be prepared and organized in order to ensure their smooth participation, i.e. scheduling synthesis sessions in advance, planning consistent updates and debriefs, outlining the purpose and goals of each session clearly. This can add up to a few extra hours a week and if you are flying light on capacity, this could pose a problem. It’s better to go slower knowing that you will have a green light at the end, rather than fly through and have to throw it all out because folks don’t agree with you.

Discovery and Framing are team sports, and not just the Product Team. Do whatever you can to make sure that people outside Product understand what goes into creating a product, and work on getting their support and buy-in. If you can do that, you’ve achieved the dream scenario, and who doesn’t want that?

 

Every Team in the World Should Do Retros

Recently, over breakfast of chilaquiles with my colleague Andrei, I once again found myself extolling the virtues of the only meeting type in the world that I wholeheartedly love: The Retro.

Andrei and I were having a working breakfast about our company Remote Year. Andrei came on board a few months ago as a Programs Team Manager and works with teams that lead 3–4 of our programs. The talk eventually drifted to feedback and Andrei asked if I had any thoughts on how to best structure feedback sessions and then how to capture actionable insights.

As the question was coming out of his mouth, I started to jitter with excitement, as I always do when I get to tell someone new about the beauty of a Retro, but let’s back up.

Retros are a 1-hour meeting that are held regularly and allow teams to review what went well, what went meh, and what went badly about the work that has been delivered in the past week, two weeks, or month.

I first experienced a Retro when I was with a company called Case Commons, then a client of Pivotal Labs NYC. I learned then that Retros are best done on a Friday afternoon, usually with an open beer, in a relaxed atmosphere. The session starts with a facilitator drawing a happy face, a meh face and a sad face on a white board or on a shared google doc. For roughly 10 minutes the team members independently write down what they feel was great, shrug and bad about the work that has happened leading into the Retro. Teammates can +1 stuff that they agree with.

Template for Retros

Everyone then sits down and the facilitator touches on each thing from the column, mixing it up between the faces, until all are discussed. They ask for teammates to sound off on what is implied by each piece of feedback. Anything that becomes a larger discussion should be parked and have an action item applied to it. The sad column should produce a number of activities in the Action Items column that are intended to improve or remedy the things that did not go well. Individuals should volunteer or be assigned responsibility for Action Items. At the next Retro, the facilitator should review the Action Items from the last one, and see what’s been done or not done.

Despite the eye-rolling nature of this phrase, Retros should be safe spaces for the team to discuss mistakes or things that went poorly. Feedback should be given and be meant kindly. Retros should embody a spirit of “No Blame” culture so that issues can be discussed freely and honestly. Make no mistake, getting a team to sit down in person and talk freely about mistakes isn’t easy.Most people have never done it and it can be uncomfortable especially when things aren’t totally hunky-dory. It’s a muscle that teams need to exercise. That’s why the correct cadence for Retros is usually weekly. It gets people comfortable with giving feedback to each other, and also holds people accountable for the action items and helps improve things in a tangible way. This helps them believe that continual improvement is both possible and expected. Retros should not be allowed to slide off the schedule. At its heart, a Retro is a planning meeting, one specifically meant to address issues and weaknesses. What could be more important than that?

Retros are great for other reasons:

• The structure provides an opportunity to discuss positives and negatives, so that folks can remember that even when mistakes are made, good things happen as well.

• Retros work really well with 100% of team sizes. They are as effective for 1:1s as they are for large teams. I do a 1:1 retro monthly with my boss, and I’ve been in retros with teams of 30 devs.

• Retros are domain agnostic. I have a friend who has a bakery and she leads retros with her team. A friend of mine who is a lawyer has retros with her manager. The main point is to be able to address where things get have gotten sticky, and there isn’t a team or a company in the world that couldn’t use that.

• Retros are always there, people get used to that and start noting and storing feedback for them. Teams and individuals start to get more thoughtful about process and more creative about improvement possibilities. Retros help people get better at getting better.

Get better. Do Retros.

10 things PMs should do when they start at a new company

10 things PMs should do when they start at a new company

Three months ago I joined a start-up called Remote Year as Head of Digital Product. That fancy title aside, I was coming in as the first PM on the ground and the company’s first hire to a new digital product department. Remote Year is a service based company that brings together groups of people who want to work and travel the world in the company of an awesome community. I was so excited to be joining a team that was on the crest of a wave that symbolized a new way of thinking about work and life.

Remote Year is the first company I joined where software was not the driver, but an augmenter and an enhancer. I was nervous about this, but mostly excited as I am a UX-Design-heavy PM and working with user needs is my wheelhouse. I was also excited about the opportunity to bring UX research and design thinking practices to an IRL service.

Remote Year dogfoods like no company out there. It is 100% remote with a large majority of its 100 person staff traveling with or between our programs as they criss-cross the planet. I was coming from a company that espoused a philosophy of co-location as a cornerstone of good practices, so this was unchartered territory for me. I was also coming from a big company where I had designers, engineers, data scientists on my team from day one. Then it was just me, for a while at least.

Three continents, four countries and countless Zoom calls later, I’m taking stock of what has gone down and creating a list of things I did that worked well, things that I wish I had done better, and things I really wish I had done at all, though I won’t say explicitly which is which. As a team of one, (about to become a team of two) in an entirely new environment, trip-ups were inevitable, but I hope this list will be a help to PMs who are entering into any new company, as these practices can be broadly applied to lots of different orgs.

1. Explain the broad vision of your process to all your stakeholders

Whether your company is brand new to certain methodologies or old hat at agile and UX, have a conversation with the key folks you need to work with about what it IS that you do, and what the outcomes are is incredibly helpful, as many things can be different from org to org. Present an overview of agile product management, what is comprised in discovery and framing, what activities you will do at a high level, and what the expected outcomes are.

Agile, despite being nearly 25 years old, still isn’t something that is clearly understood, and how user centered practices fit into agile is even less understood. Have an hour long conversation supported with a few slides and visuals, and get folks asking questions.

2. Make it crystal clear what you need and when

During that agile overview/education session, make it clear how much you need stakeholders to participate, either in attending Discovery activities, or in attending group debriefs to discuss the insights gathered during rounds of research. Set placeholders for them on the calendar and try to make them stick. Push for this and be explicit about its importance. I’m not saying it will happen, but be clear about why you need them there.

One of the most valuable things about the Discovery process is that it will steward a team that participates to the same destination. If you’ve done all the work alone, and not brought the team along with you in incremental steps, it’s a lot longer of a journey to get them to your page as Discovery draws to a close.

3. Make sure you do constructive stakeholder interviews

When I first joined Remote Year, I travelled to Asia, so most of the folks I needed to speak to were at least 3 time zones away, and many were 13 hours behind. This, to put it lightly, threw me for a loop and I can cop to letting this one slide, but understanding what your colleagues who are guiding the company are thinking about is really important in terms of understanding implications and opportunities for digital. I’m doing them now, and it’s actually alright that it’s a bit later. I think you can grab value from this exercise at any point.

If you need a template for a good stakeholder interview, check out the book “UX Team of One,” by Leah Buley. In fact, that book is a god-send for anyone who needs process support as they figure out a new company environment.

4. Set consistent touch-points and come hell or high water, stick to them

This one is pretty similar to #2 just on the one-on-one level. There are probably 3–5 people that you should be checking in with on a weekly or bi-weekly basis. These intimate conversations are updates that help you stay abreast of what work is going on at a granular level and vice versa. This helps create transparency on both sides and assists collaboration. This is easier when you’re in the same office, but can still be challenging regardless if schedules are busy, (which they always are.)

5. Repeat back the deliverables timeline early and often

This conversation should be easier if you’ve done #1 and laid out the big picture from the beginning, but misalignments can still happen. If you’re used to doing things with certain team members, in a certain order, with certain resources, you make assumptions about when things are going to happen.

In terms of having this conversation with your boss, start with the question, “When do you expect us to start committing code?” and work backwards from there in terms of what you need in order to make that happen. Be explicit, and do not mince words. Over promising and under delivering will feel worse than saying the hard thing.

6. Immerse yourself in the product and service

The best way to kick this off is to get a group of roles in a room and do an in-depth, 2–3 hour user journey mapping. Use this exercise to get into the real nitty gritty of each role. I don’t just map the customer journey, but Remote Year staffers as well. Map as many roles as you can, and deep dive into particulars if possible. I had a two hour session and then four additional interviews to fill in the gaps. The User Journey Map should give you as good a sense of the inner machinations of the org and service as possible.

Unfortunately, I had to wait quite a while to get the right group in the same room (and user journey mappings don’t work over Zoom,) so I started immersing myself by joining programs and participating in the service itself. Watch how things work, listen to conversations that are happening, constantly take notes, be a fly on the wall, keep your eyes open as you watch how people interact with colleagues and customers. This helps you conduct better…

7. Do user interviews

Obviously as you’re doing Discovery, you’ll be doing a lot of things, but NOTHING is EVER as important as doing user interviews for a new PM coming into a company. Once again, I point you to UX experience Team of One if you need a reminder about a script template. Create a script that allows you understand the motivations, the incentives, the challenges, frustrations, pain points and current tools of your customers. The ultimate question you’re asking yourself is “How are things happening for my customer now, and what should change first?”

Trickiest thing about an interview: it has to feel like a conversation but still collect consistent data. It’s your job to guide towards this outcome. At Remote Year our customers are whip smart people who have a lot of questions for me. I view it as a sign of respect to them and the product to get the most out of the interview by saying “we can grab a coffee after and chat through those questions, but I really want to make sure I get your thoughts on a few things and these sessions fly by.” They’ll understand that this isn’t a casual chat, but actually that I’m taking the exercise and their time seriously.

8. Synthesize, and then find ways for others to use the insights gathered

I had to make the switch from post-it synthesis to Trello board synthesis so I can share it out more easily. I have also realized that synthesis is so much better if it’s done with someone else. So if you’re hanging on your own, do your darndest to pull in some of your colleagues into the process.

If you can, pull in colleagues who will derive a lot of value from seeing organized insights from your customers. I’ve really enjoyed pulling in folks from various corners of Remote Year and bringing them into the insights conversation. I hope to do this a lot more often in the coming months.

9. Don’t beat yourself up

This happened to me a lot. Things felt like they were moving very slowly, not surprising given I was doing the job of a three person team alone. I knew that things like stakeholder interviews were slipping, I wasn’t sure when I would get people together for a user journey map. I was having trouble finding time to do the work and then communicate what the work was indicating. At times, I didn’t prep enough in advance to get stakeholders involved. I was away from home. It was tough.

But… I am also traveling the world for my job. Meeting incredible groups of new people each month, and getting to know colleagues who are some of the most wonderful people in the world. I get to go to the beach in Mexico. I say things like “I think March is going to be in Lima.” I’m also working on creating products for a company that is the first mover in a new way of working, and is blazing a trail into a way of life that is bringing joy and inspiration to its customers. When you get down, take stock, remember the good stuff, make a list, and get started again.

10. Call your PM buddies (and data scientists and devs)…a lot

When I would get stuck this is the thing that would get me unstuck the fastest. I am so lucky that I have worked with so many amazing people in the past who I can call friends, who are willing to give of their time and ears to offer perspective and advice. Reaching out for help is not admitting you don’t know, it’s admitting that a conversation will assist you in getting there. Thank you to my squad for all of the good stuff you’ve given me over the past few months and looking forward to more learnings in 2017.