Don’t Fear the Future

Lamb Book CoverI just finished reading Lamb: The Gospel According to Biff, Christ’s Childhood Pal by Christopher Moore for fun, and it was a great read. It is a humorous take on Jesus’ childhood, wherein he visits several wise gurus alongside his friend, Biff. One quote in particular stuck out to me:

“All fear comes from trying to see the future, Biff. If you know what is coming, you aren’t afraid.” (p.231)

To me, this was an intriguing take on the one of the most important and challenging responsibilities of a Product Manager: to create and communicate a vision for the future. If a Product Manager does not do this well, there will be fear as team members and stakeholders are left to prognosticate on their own. They won’t have the full context of solutions that are viable, feasible, and usable, and will thus assume the future will fail in one or more of these aspects. From unsellable products to technical meltdowns, everyone has a boogeyman product that they never want to revisit. And this nightmare project is the first thing that comes to mind for them when they think about what might happen. A Product Manager may see this fear in decreased team productivity, lose of stakeholder trust, and time wasted squashing rumors.

So what can a Product Manager do to avoid this fear? By creating a clear vision, using Lean Canvases and other methods to show the “what” and “why” for the plan, team members and stakeholders can see the future. A plan doesn’t magically make everyone agree, and folks will certainly question the plan and raise risks. This questioning is healthy as it gets their fears out, helping to refine the plan and focus the vision in the places that matter the most for them. Iterating on a plan ultimately leads to a supported vision that everyone can rally behind.

The next time, or the first time, you’re making a plan for the future, think about what you’re doing to remove fear for your team and stakeholders. I think you’ll find the planning, even if it can be repetitive, is more engaging when you think about the emotional relief you’re providing to others by helping to remove fear from an unknown future.

The First Product Demo

A new Product Manager needs to demonstrate expertise in a product to gain respect and trust from others in the organization. A great way to prove this expertise is by giving a product demo to a set of internal key stakeholders and SMEs for feedback. This important audience will be able to see that the PM understands the product features, how those features contribute to an effective sales message, and get a chance to give the PM feedback for when they need to demo the product for customers. These key stakeholders are typically folks from the development team, marketing, support, and other product managers. The demo can take anywhere from 30-60 minutes depending on the product, and can be formatted however the new PM wants, as long as there’s time for questions and feedback. Since Jenni is helping manage 5 products, she’s doing three of these demos to cover the various product lines.

Whether the new Product Manager has given demos before or not, hopefully the tips below will help them be successful for their demo to gain the trust they’ll need to be successful.

    • Do your research – Talk to key stakeholders ahead of time to get their views on the product. This especially goes for Sales and Marketing where hearing a sales pitch or up-sell message will give great material for this demo.
    • Tell a story – A story helps give a foundation to your demo as well as win interest from the audience. Tell a compelling problem that brings users to your product, and how your product relieves user pain.
    • Use real data – Partner your story with screenshots or a live demo that shows a user’s account in action. This makes the story real and tangible. Screenshots remove any complication from technical, but for this demo a live account gives more opportunity for the stakeholders to give feedback or ask questions.
    • Focus on benefits instead of features – As the demo shows off the product, focus on the customer benefits and advantages in the marketplace rather than features. This shows understanding of how the customers use the product as well as mastery of what’s really important to customers.
    • Leverage analogies – Having analogies for various product concepts can help communicate what a product does and set up a quick foundation for product concepts. There are likely several analogies that Sales and Marketing use when describing the product to new prospects, and the PM needs to be aware of how they’re used.
    • Strike the right level of complexity – A great demo knows the audience, and sets the complexity at the right level. For this demo the complexity will be more than a real customer demo, but don’t get too distracted by details during the demo or the demo will easily take too much time.

Avoiding Distractions With Pomodoro

By Erato at Italian Wikinews via Wikimedia Commons
By Erato at Italian Wikinews via Wikimedia Commons

A Product Manager’s job is full of distractions. From support issues to pressing Team questions, the day can fly by with time only spent on what’s “urgent” rather than what’s “important.” It can be especially difficult for a new Product Manager to control the constant interruptions as their prior role was likely not interrupt-driven. It’s thus important to help a new Product Manager learn techniques that can help them be efficient with their day. Pomodoro is one such excellent technique, and a great one for you to either learn along with a new Product Manager or a simple method to teach them.

The Pomodoro Technique offers a simple approach to creating space in your day for dedicated focus on important items. A Pomodoro is 25 minutes of uninterrupted time, followed by a 5 minute break. Of course you must defend the Pomodoro from distraction by turning off your computer’s notification (Mac’s “Do Not Disturb” feature is great) and silencing your phone. You then set a timer, either physical or on your computer, for 25 minutes and get to work. You don’t get up for a coffee, you don’t check your email, and you don’t change your Pandora station. You just focus on the task you’ve assigned yourself until it’s done. If an interruption occurs, such as someone coming to your desk, you ask them kindly if you can get back to them at your next break (up to 25 minutes from now). If you tell them that you need to focus on an important piece of work and will get back to them shortly, they’ll understand. And if something truly urgent and important comes up, you cancel your Pomodoro to handle it, but you get no credit for your partial Pomodoro.

When the 25 minute Pomodoro is done, give yourself a pat on the back, and take a break from your computer. Get up, stretch, grab a drink and use the bathroom. Then come on back and sit down for you next Pomodoro. Practice makes perfect, and one of the key rules for Pomodoro is “The next Pomodoro will go better.” When first learning the technique try it out during a time that naturally less filled with interruptions to get in the habit.

For your timer, some folks like a physical kitchen timer as they love the feel of winding the clock. You can’t easily cancel a kitchen timer, and they find the quiet tick-tick of the clock soothing. For me, I prefer a virtual timer as it’s quiet for my co-workers and I like to listen to music while I work. You can find many free options, and on Mac you can search the App Store for “Pomodoro” for many choices.

There’s much more to be covered to be effective on the Pomodoro technique, and I’ll cover advanced techniques in future posts. For now, this is all you need to get started, to give yourself 25 minutes of focused time in your day. Try it out and see how effective you can be with some Pomodoros. If you want to learn more now, check out this free 40 page PDF ebook.

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.

Service Design – Classify your Service Model

14-service-design-320x480I’ve started leading a book club at work for Service Design and it’s creating some great discussions around how to improve our service setup. This week we covered Chapters 1 and 2, which gave an overview of how a Swedish insurance company used service design and the basics of service design. As we progress through the book I’ll post about interesting ideas and discussions.

One of our first talking points was around the notion of classifying services in one or more of the following values:

  • Care – Services that maintain people or things, such as healthcare or airplane maintenance.
  • Access – Services that enable people to use something temporarily, like a car rental.
  • Response – Services that respond to people’s unforseen needs, like an insurance policy.

For a new Product Manager, this classification of a company’s service values can help them think about a product holistically. A great point in the book is that many businesses silo parts of a customer experience into business unit to optimize organizational structure, but the end customer receives the service as one package. It can be all too easy for a new Product Manager to think only about product development without considering how product decisions impact the overall service that a customer receives. And that a customer’s experience with your company is shaped only partially by the product experience. It’s important to work across the business with all stakeholders, incorporating internal needs into product design and communicating profusely about any service impacts.

At work we’re in the midst of transitioning from Access and Response values to Response and Care values, which is an exciting time to explore new ways to structure our services. It also means that the tone and value proposition of our products has to change to support this new service model. Viewing the service change as a fundamental shift in service values helps give a measure for examining product changes. Any product change I make should be about getting us away from an Access value to a Care value. For instance, instead of giving customers access to raw exports of data, we should be caring for them by bundling that data into actionable recommendations that can easily implement.

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

  • Gjensidige had their CEO and Executive Team talk to customers. What effect do you think direct Executive Team involvement would have/has on our services, both internally and externally? From the book – “When a CEO sits down to talk to customers to find out what they think, it sends an important signal to the rest of the organization and the industry.”
  • Where are we siloed as a service organization, and where are we not? What impact do these silos or lack thereof have on our customers? What could we do to help bust any existing silos? From the book – “The division of the silos makes sense to the business units, but makes no sense to the customer, who sees the entire offering as one experience.”
  • How do we think and talk about our customers: as productive assets or as consumers? From the book – “The biggest missed opportunity in development is that organizations don’t think about their customers as valuable, productive assets in the delivery of a service, but as anonymous consumers of products.”
  • Services deliver one or more core values: Care, Response, and Access. What are our service values? Is it different depending on the product/value proposition?
  • How could we make our service more visible to customers? How do we make the invisible visible? From the book – “As a result, service designers frequently need to make the invisible visible by showing customers what has gone on behind the scenes, showing staff what is happening in the lives of customers, and showing everyone the resource usage that is hidden away.”

The Kano Crystal Ball

Kano_model_showing_transition_over_timePreviously I talked about how to do a feature inventory with Kano to help onboard a Product Manager. Kano can help them feel acquainted with a product’s feature set and understand how customers engage with your product. You should also use Kano to take a look at customer feedback and upcoming plans. Classifying the planned features into the Kano emotional responses gives the same insights as the feature inventory, and also helps ground a product’s upcoming plans.

An important aspect of Kano when viewing future plans is that your customers’ emotional responses to features change over time. Features that were once Delighters will become Basic Needs as customers get habituated to such functionality and your competitors match you in the market. When looking at the roadmap, I like to first check that Basic Needs are met at the minimal level to reap the large returns on removing customer dissatisfaction. Basic Needs are “check the box” features, so as long as you check the box you’re good, and there’s little benefit to putting extra effort into making the “box’s check” fancy. I try to keep the MVP philosophy in mind to get the most value for the minimal effort when working with Basic Needs, as I’d much rather focus on Delighters. Delighters deserve the focus for several reasons:

  • They age better – By building a Delighter today you can reap value from that feature for a while as it ages into a Basic Need. If you were to focus only on Basic Needs, your customers would lose interest in your functionality sooner as they age into Indifferent features. The longer lifecycle for Delighters gives you more time to focus on improving customer satisfaction even more.
  • Competitive Advantages – Delighters give jet fuel to your marketing and sales team as they are often competitive advantages that can be touted in demos and marketing materials.
  • Team Motivation – Delighters are often much more fun and enjoyable to create as they are innovative and rewarding to customers. They give your dev team a challenge and boost morale which in turn creates even more innovation.

Kano can thus be a crystal ball that predicts how your features will fare in the marketplace over time. By knowing your customer’s emotional response to your current and upcoming features, you can extrapolate how those features will age over time as the emotional responses change. Reviewing the product plans with a new PM will help them know what to be on the lookout for in customer discovery as well as where to look for Delighter opportunities when creating new features.