The Two-Week Checkin

"Crystal Clear app date D14" by Everaldo Coelho and YellowIcon
“Crystal Clear app date D14” by Everaldo Coelho and YellowIcon

This week marked the end of Jenni’s first two weeks, so we took a moment from a hectic week to see how things are going and how we can improve. I’m a big fan of regularly scheduled retrospectives and checkins. Not only do they ensure a team is thinking big picture, it gives a safe space for giving feedback. Whether a team is doing great or unexpectedly poorly, a regularly scheduled checkin gives a chance for team members to voice complaints or thoughts for improvement.

I kept the checkin informal to allow the conversation to go wherever it needed to go. The goal was to get Jenni’s opinion on how onboarding is going, fill in any missing puzzle pieces to solidify her knowledge, and identify risks to meeting her 30-day onboarding goals. Below are my conversation-starters that you could use in an onboarding checkin too. For all of them, be sure to ask “Why?” to get the most out of them.

  • What one word best describes your onboarding experience?
  • What’s been your favorite moment so far?
  • Has your onboarding matched your expectations for being a Product Manager?
  • What’s still confusing in what you’ve learned?
  • Have you met anyone that you aren’t sure what they do?
  • Are you feeling confident in meeting your 30-day onboarding goals?

I expect to have such checkins at least every two weeks to continually improve Jenni’s onboarding experience.

Service Design – Service Blueprinting

14-service-design-320x480The third session of the Service Design book club covered Chapters 5 and 6. These chapters cover techniques for describing services, which fed well into work we are doing this quarter to improve our customer experiences. Jenni and I took the opportunity to try the book’s technique of service blueprinting to create a holistic view of our customer’s experiences. If you have not read the book, I think you’ll find this technique useful as it’s easy to apply without full understanding of service design. And if you have read the book, you know the examples in the book are hard to read and/or not in English, so hopefully this shows a real-world example.

We spent a couple hours creating our service blueprint, using a whiteboard and big stickies to easily change our approach as this was our first time service blueprinting. We started by drawing several swimlanes on the board (where TBD are blank spaces):

Physical Evidence TBD TBD
Customer Actions TBD TBD
Onstage TBD TBD
Backstage TBD TBD
Product/Systems TBD TBD

We then created the backbone for our service in large stickies. A key point from the book is to set a boundary for the blueprint as it can easily get out of scope if you don’t constrain it. Our backbone had about a dozen stages, with the first couple looking like this:

Physical Evidence Signed Contract Welcome Email
Customer Actions TBD TBD
Onstage TBD TBD
Backstage TBD TBD
Product/Systems TBD TBD

We then gave detail to each stage to show what the customer, onstage, backstage, and product actions are. Many of our stages had blanks for some areas as there are not activities onstage or backstage.

Physical Evidence Signed Contract Welcome Email
Customer Actions Product/Service Selection First Login
Onstage Contract Negotiation Welcome Text
Backstage Legal/Finance Account Provisioning
Product/Systems Provisioning System Email Automation

We tracked our open questions and ideas for improvement along the way on different stickies. At the end we had one of our key service reps join us in the room to review what we created, which led to some great conversations and corrections to our understanding. Most notable were discussions around how certain product features aren’t used by our teams as we thought they were, and around how we could make the final contract termination stage better to help our customers stop using our products.

I think the experience was great with a new PM for a number of reasons:

  • The blueprint creates a foundation for understanding our full customer experiences, not just the product interactions.
  • Trying a new technique together gives a space to experiment and collaborate towards a shared success with a blueprint artifact.
  • The stakeholder review at the end helped form a key relationship for Jenni.
  • The blueprint creates shared understanding for Jenni and I which can be used between us as well as with the development team and stakeholders.

We are planning on sharing the blueprint with others as a scaffold for this quarter’s work and to further validate some of our improvement ideas. I think it was a successful activity and would recommend it, especially for product work that impacts a customer across multiple touch-points in their life cycle.

If you are interested in hosting your own Service Design book club, here are some discussion questions from these chapters:

  • What did you think of Service Blueprinting? Should we set up a workshop to create one? From the book, where the importance of the mapping activity is highlighted: “First, it wasn’t the map itself, but the mapping.”
  • A theatrical metaphor was used to describe frontstage/backstage service activities. Did this resonate with you? Why or why not? From the book “Shostack’s line of visibility has transmuted into the frontstage/ backstage metaphor in which anything that the “customer” experiences is frontstage (on-stage would be more appropriate to the metaphor) and everything else that goes on behind the scenes to make that happen is backstage.”
  • Are there backstage activities that we could bring frontstage to improve our service experience? From the book “Often, this backstage activity is evidenced in some way by bringing it frontstage, such as the folded toilet paper tip in a hotel bathroom that indicates the room has been cleaned.”

Service Design – The Spirit of Discovery

14-service-design-320x480For the second session of the Service Design book club, we covered Chapters 3 and 4. These chapters focused on the importance of research and many techniques to gain customer insights.

For a new Product Manager, the techniques discussed in Chapter 4 are a great introduction to the tools in the discovery tool belt. And more important, these chapters stress the value of discovery in gaining insights that power service design decisions. As you train a new Product Manager, it’s helpful to take this same spirit of discovery in talking about new ideas that the new PM may have. Rather than dismissing a new idea due to your preconceived notions of what’s best, take the stance that the new idea is worth testing. Talk to the new PM about how their idea can be validated, either through existing data, interviewing internal stakeholders, or reaching out to customers. And be comfortable saying you don’t know what’s best. By showing how you go about learning and gaining customer insight, you’re teaching the new PM “how to fish” rather than giving them the “fish” of your prior experience.
As we covered this section at work, we had a fruitful conversation focusing on how our Customer Experience (CX) Team currently shares insights and how we could do it better. Our CX Team has a blog, and we knew we could drive more internal traffic to it. We talked about ideas such as adding new posts to Slack or Chatter and creating posters of valuable insights to distribute. As the HourSchool case study suggested, we also talked about ways to better ingrain CX into existing standing Services meetings to make customer insights a regular part of our services planning and give it continual focus.

If you are interested in using Service Design for you own book club, here are some discussion questions you can use for Chapters 3 & 4:

  • Do you agree with the focus on qualitative over quantitative research? Is it better to get 100 insights or 10 truths from research? From the book: “Statistics are not very actionable for designers—we need to know the underlying reasons.”
  • Do we utilize our internal staff enough when performing research? Are there ways we could utilize them better? From the book: “When time is short and a service improvement project has a limited budget, it is often a good idea to prioritize the research time with staff and data to dig quickly into the detail that is needed to design great services.”
  • The HourSchool case study mentions that research became a regular part of meetings. Would it be beneficial to make research updates and recruiting a regular part of Service Team meetings? From the book “Announcing new classes, soliciting requests, and recruiting volunteer organizers are now standing agenda items.”
  • As we learn about Service Design and create exciting improvements to our Services, how can we ensure our actions and momentum continue on? From the book: “Service innovation should have a lifespan beyond the length of time the service designers are involved in the project. This means recognizing that other stakeholders may engage in many of the activities of service design as part of a continual process of change.”
  • Were there any discovery tools you’d like to try? Should we do a Service Safari together? Should we put together a Brand Sheet to use in discovery with customers?

Viable, Feasible, Usable

viable_feasible_usableA Product Manager creates solutions that are viable in the marketplace, feasible to build, and usable by customers.

That is my 5-second answer to “What does a Product Manager do?” Everything that a Product Manger does, from customer discovery to writing stories to press releases, comes back to these core values for any solution. I’ve found time and time again it serves as a great framework for thinking through solution creation. All three values are equal and can be presented in any order:

  • Viable – Will Customers buy the solution? Product Mangers must test market demand and understand the marketplace for their solution. This often includes working with Marketing and Sales.
  • Feasible – Can we build the technology needed for the solution? Product Managers must work closely with developers to scope and assess the solution in terms of time-to-build, security, and performance.
  • Usable – Can Customers understand the purpose of the solution and how to get value from it? Product Manager collaborate with UX designers to create customer-friendly solutions.

This framework is also a perfect base for setting onboarding goals for a new Product Manager. A new PM needs to gain mastery of a product quickly, and thus these goals reflect these three values:

  • Viable – A new PM needs to understand and communicate the business model for a product. This includes understanding the unique value proposition (and thus the competitive landscape) as well as cost and revenue streams. The PM can prove mastery of a product’s viability by creating the Lean Canvas or Business Model Canvas for the product.
  • Feasible – A new PM needs to understand the technology behind the product. Typically a PM will work with one or more developers to get a technical overview of the product, and then demo it back to the developer and others later to show they have internalized the technology and can speak to it. The PM does not need to understand every minutia of the technology, and just enough to collaborate with developers and understand what is feasible to build.
  • Usable – A new PM needs to understand the ins and outs of every feature of a product, and how Customers use them. As with the technical demo, the PM should be able to demo the product to stakeholders to show mastery and build trust from stakeholders that they know the material.

In setting 30-day goals for a new PM, I set the goals of given the technical and feature demos (feasible and usable mastery), and then have the canvas (viable mastery) created in the 60-day goals. The viable mastery goes past the first 30 days because it typically requires more special knowledge of how to create a Lean or Business Model Canvas. If a new PM is already well versed in canvas creation then that goal could come sooner, and another one potentially pushed out of the 30-day goals to the 60-day goals to give more time for special knowledge acquisition, such as understand what databases are.

Jenni is currently working through these goals as part of her onboarding by getting technical demos from developers, getting product demos from myself and training, and joining sales calls to understand the product position in the marketplace. Each aspect of the product builds on the others, so attacking all three values of a solution at once helps create an even base for being a strong PM for a product. In future posts I’ll dig in more on how these goals are accomplished and structured.

Focus on “Why?”

"Why" courtesy of Ksayer1 on Flickr
“Why” courtesy of Ksayer1 on Flickr

Recently I had to quickly learn about a product from another expert as he was leaving the company. Through past experiences, there are two things to keep in mind when taking over a product on short notice. First, schedule several 30-minute sessions with the former expert as soon as you can, as their calendar often books up fast in their final weeks before going out the door, and invaluable ‘brain-dumping’ and knowledge sharing can be forgotten. I’d suggest spreading a couple sessions out over the final weeks or days so you have time to digest and research between each to get the most out of them.

Second, instead of focusing on the ‘what’ or ‘how’ of a product, focus on the ‘why.’ Many people in an organization know what a product does as they must sell or support it, or how it works because they’ve had to technically maintain it, but very few understand why it behaves that way. Knowing the ‘why’ relies on historic knowledge, of being there when something was built, and is thus easily lost when someone leaves the company. These reasons may be technical limitations, customer learning, or just features that had to be slimmed due to the time constraints. Others in the company may assume these product limitations are non-negotiable or are based on non-existent research and thus should not be changed. Only the former expert knows the real truth for why they’re that way, and how things that are considered sacred were initially due to temporary constraints.

One example in my recent knowledge transfer for why ‘why’ is important was around the product’s icon set. Some of the icons aren’t intuitive, and the reason why they’re that way is because the UX designer wasn’t available at the time they were added, so a Developer chose them. Without knowing the ‘why’ I might think the icons were based on customer feedback or discovery and thus should not be changed, but the truth is that I could easily correct them to something more intuitive.

When training a new Product Manager, the same focus on ‘why’ is important. Teaching the rationale behind existing features and prior decisions gives a framework for knowing the product, its history, and the customer context. And knowing the ‘why’ gives the new Product Manager confidence to make their own choices and decisions founded on prior research. They can also use this ‘why’ to show expertise in the product when working with stakeholders, quickly owning a mastery of the product by having the lesser known, but very important, ‘why’ behind features.

So whether it’s you learning about a product from an existing expert, or you’re teaching your expertise to another, focus on the ‘why’ for features to ensure you get the full story and know the real reason the product exists as it does.