Start making better product decisions: A framework to go with your Agile Process

Guest Post by: Alex Hsu (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Addi Regev]

Why do I need a framework?

A research conducted by Alpha UX found that 25% of Product Manager surveyed wished for a clearer product roadmap and strategy. This was second only to increase in salary!

clip_image002

Research article

While salary increase is a complex subject with variables outside of our control, I believe that having a clear product roadmap and strategy is every Product Manager’s responsibility. Without a clear roadmap and strategy, a Product Manager won’t be able to make impactful decisions. And over time, this can mean the difference between a successful versus a failed product.

So to help you achieve this goal, I’ve laid-out a foundational framework that can be used to store and organize incoming product requests into repositories that describe your product’s strategy. Once implemented and properly maintained, this can help you obtain the goal of having a clearer roadmap and strategy, which should help make good product decisioning easier.

Lastly, to make the most out of this framework, it’s best if your organization has already implemented some variation of the Agile Methodology. If not, this can still be applied to most existing process with some tweaks.

Enough talking. Show me the money.
Themes, Epics, User Stories

To start, break down any incoming feature requests into Themes, Epics, User Stories using the following suggestions.

Themes are critical building blocks for your product’s strategy, each Theme is usually a statement describing an idea that is critical to the vision of your product. Epics are large features that together makes up a theme. Lastly, User Stories are “chewable bits” that together makes up an Epic.

To help illustrate the relationship between Themes, Epics, and User Stories and how they can be applied in practice, I’ve included an example of the hierarchy between each item and how they can be written within the context of a fictional spaceship company.

clip_image003

Example User Story:

A User Story is a description of a functionality written from the perspective from the person requesting the capability.

The User Story should be structured to include:

  1. The requester’s role
  2. The desirable outcome once request is delivered
  3. The benefit to the organization or end-user once request is delivered

For Example:

“As an Astronaut, I want an altimeter to tell me my current altitude from the surface”

For more details about writing a good User Story, refer to this article.

Each of these items are also useful when communicating your product’s strategy to various stakeholders within your organization.

Themes typically describes abstract ideas or concepts critical to your product vision. As a result, they are useful when discussing product strategy with senior management or describing your product at a higher-level without getting into details.

Epics and User Stories, on the other hand, should be concrete features or tasks that are useful when explaining and assigning work to designers or engineers. Epics are also useful when describing features to an end-user of your product or service when collecting feedback.

clip_image004

For more details about Theme, Epic, and User Story, refer to this article.

Quarterly Objectives

This document can be used to communicate quarterly objectives that you hope to achieve. Items that go into each quarter should be made up of Epics or a features you hope to achieve.

Below’s an example of how objectives can be structured:

Q1 2017

Q2 2017

Q3 2017

Rocket Booster

Navigational Computer

Spacesuit

Ions Engine

Sleeping Quarter

Detachable Landing Vehicle

Pilot Cockpit

To maximize its potential, all Items included in this list should be shared and discussed with your business stakeholders so it’s aligned with their needs. A well understood set of quarterly goals where all business stakeholders share the same understanding of the deliverables and their priority is critical for business planning and external communications.

Second, each item under Quarterly Objectives should be traceable to a Epics or Themes so they can be worked on. If done correctly, this document can be a powerful tool that motivates your design & engineering team by setting ambitious yet achievable & well-planned goals.

Third, this will be one of the most important documents that can be used when trying to make product decisions. By looking at this list, you should be able to identify valuable requests and their priority within the overall roadmap.

Lastly, always leave room for changes in scope and timeline to account for gaps in estimation or other factors that might be out of your control. Also, shift the time period according to the context of your product or organization, as an example, an early product that’s still trying to find a market might have a shorter timeline compared to a more mature product.

Milestones

Finally, you want to set achievable Milestones. Each Milestone should be a plan that contains a deadline as well as an agreed upon set of User Stories or Epics (Let’s call these scope). The scope and deadline should be understood and agreed upon by any party involved in the planning process.

To maximize their potential, tie deadlines to meaningful business events that help market your product to its intended Target Audience. Some example can include tradeshows, product summits, or client demos.

Below’s an example of how Milestones can be structured:

Milestone 1
Tradeshow
(1/15/2017)

Milestone 2
Client Demo
(12/25/2017)

Rocket Booster
Space Suit

Ions Engine
Pilot Cockpit

Try to avoid any changes in scope and timeline once agreed upon by all parties involved. Unlike the Quarterly Objectives, if done correctly, a milestones should be tied to a business event where audience should include external prospects or clients. These type of audience are typically less tolerant to changes in expectation that has been communicated to them prior.

But why did I choose this framework?

I chose this framework because of two major reasons:

  1. It can be used when communicating across any layer of management or external stakeholders
  2. Its wide-adoption across most industries and company sizes means there are various tools and resources to choose from.

As a result of its wide adoption, there are various tools and resources built around this framework each targeted to fulfill the needs of their target market, the following research data compiled by Alpha UX shows most commonly used planning tool amongst Product Managers surveyed and can be served as a directional indicator when choosing the tool to implement within your organization.

clip_image006

Research article

So… What’s next?

I wrote this article hoping that it will help Product Managers stay more organized and make better product decisions.

This is not meant to be a one-size-fits-all solution, I would strong encourage you to reflect on this framework within the context of your product and organization’s need and come up with your own evolution of this framework.

For additional readings. I recommend visiting the following sites. Each of these sites contains an array of articles that dives deeper into various subject related to the Agile process & framework.

https://www.mountaingoatsoftware.com/blog

https://www.scrumalliance.org/community

http://pragmaticmarketing.com/resources/blogs

https://tpgblog.com/

I would also like to thank Addi Regev who spent portion of her weekends providing constructive feedbacks and suggestions that helped formulate this article.

 

About Christopher Davis
alexhsu

Alex is a product manager with years of experience in B2B Digital Marketing space. In addition, Alex also has made it his goal to grow and motivate teams to build better products that delights end-user.

Outside of his profession, Alex has made it his personal mission to promote cross-cultural awareness through use of cutting-edge technology. Alex maintains a blog where he writes about product, technology, and travels.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Advertisements

How to Quickly Prioritize Your Product Backlog

Guest Post by: Christopher Davis (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Jonathan Berg]

id_1406_608[1]

As a product manager, you’ll often find yourself with a growing backlog of user stories and product defects that need grooming and scheduling. But which ones should come first, and why? A  robust ranking framework is key to answering these questions.

Sometime after beginning my work as a product manager at Bandsintown, I was introduced by my product mentor, Jonathan Berg, to a framework that allows me to confidently justify my decision-making to key company stakeholders and to align my goals and priorities to those of the broader business. Because every team’s needs may be a little different, the framework can be adapted to many situations.

With this framework, you will be able to promote more effective communication with your development team, reduce re-work, and prioritize which defects to work on, ultimately allowing your team to achieve a much faster time-to-market. Following successful implementation of this framework, you should feel that you’ve improved your operational product management skills, focused your day-to-day activities, and increased your team’s productivity.

USER STORY PRIORITIZATION

To prioritize our user stories, my team implemented a simple story ranking system adapted from Michael Lant, founder of projectyap.com. In theory, we assign both urgency and business value a separate number from one to five, then we multiply the two numbers to determine a story’s final weight. This weight is mapped on a two-vector matrix to help us visualize and prioritize the story in our upcoming roadmap.

In practice, I plug each user story’s rankings into a scorecard inside Aha!, a wonderful product roadmapping software tool my team uses in conjunction with JIRA. Before joining The Product Mentor program, I had already toyed with Aha!’s default scorecard system in an attempt to implement fibonacci sequence story sizing with my engineering team. Ultimately, I found it daunting, causing me to ignore the feature and us to return to time-based story sizing instead of point-based sizing.

Below is an example of Aha!’s default scorecard:

After my mentor introduced Lant’s system to me, I revisited Aha!’s scorecards and decided to create a custom scorecard for user story management. This is what it looked like at first:

The values for urgency relate to immediate impact, dependency of other stories, and timeliness of delivery. For example, a story with an urgency ranking of 1 might have no time constraint and very little impact, while a story with an urgency ranking of 5 might be extremely time constrained, have many dependencies, and must be completed immediately to have any meaningful impact.

The table below provides Lant’s example wording for ranking a story’s urgency:

5

Extremely time constrained.

Extreme level of dependency of other items on the completion of this task

If not completed immediately there is little or no value to doing it

4

Highly time constrained

High level of dependency of other items on the completion of this task

Important to go into the next sprint because of customer or contractual requirements

3

Moderately time constrained

Moderate dependency of other items on the completion of this task

Desirable to complete in the next one or two sprints

2

Minimally time constrained

Minimal dependency of other items on the completion of this task

Completion in the next two or three sprints is adequate

1

Not time constrained

No dependencies

Little or no impact

The numbers for business value relate to the level of competitive advantage, impact on brand/reputation and the number of customers the story is important to. A story with a business value of 1 might be important to very few customers with little impact, while a 5 might be important to every single customer and/or critical to the survival of the business.

The table below provides Lant’s example wording for ranking a story’s business value:

5

Extremely important to most or all customers

Extreme impact on brand or reputation

Critical to the success of the business

4

Important to many customers

Significant impact on brand or reputation

Significant competitive advantage

3

Important to a moderate number of customers

Moderate significant impact on brand or reputation

Moderate important competitive advantage

2

Important to only few customers

Minor impact on brand or reputation

Minor competitive advantage

1

Important to only a few or even no customers

Little or no impact on brand or reputation

Little or no competitive advantage

Now, how do you make the work actionable once you’ve assigned each story its numbers? That’s where priority comes in. Below you’ll see Lant’s original story priority matrix:

After mapping your story across the priority matrix, you need a color-coded key to help you decide when to take action. Below is Lant’s original story priority key:

After creating my original Aha scorecard, I began using this color-coded matrix and actionable color key with my own team. Due to resource constraints, I quickly realized that my boss and organization in general is a bit more comfortable with addressing 6’s, 8’s and 9’s at a later point on the roadmap than Lant suggests, so we adjusted the story priority matrix to look like this:

DEFECT PRIORITIZATION

After my team had a system in place for prioritizing user stories, we began struggling to work in defects. “Can’t we use the same framework?” I wondered, and as it turns out, we could!

Leveraging another article from Michael Lant, we created a matrix to work from that was similar to our story matrix, but with different criteria that made a little more sense when addressing a defect (also known as a bug, or whatever you want to call it).

To prioritize our defects, we changed what’s on the X and Y axis of the two-vector matrix. Instead of urgency, we use scope, and instead of business value, we use severity. For each, we still assign a number from one to five, then we multiply the two numbers to determine a story’s final weight.

I went to add a second scorecard in Aha! after settling on these criteria and I realized that the software only allows you to assign a single scorecard per product. This was a problem. My solution was to combine both defect and story prioritization into one scorecard.

View an example of the combined scorecard below:

For defects, the values for scope relate to the amount of users affected and the amount of system functionality affected. For example, a defect with an scope ranking of 1 might affect a very small set of users and/or a tiny piece of system functionality, while a defect with a scope ranking of 5 might be affecting all users of the product and/or most system functionality.

The table below provides Lant’s example wording for ranking a defect’s scope:

5

Affects most or all users and/or a very large range of system functionality

4

Affects a large set of users and/or large range of system functionality

3

Affects a moderate set of users and/or moderate range of system functionality

2

Affects a small set of users and/or a small range of system functionality

1

Affects a minimal set of users and/or a very small range of system functionality

The values for severity relate to how easy it is to get around the defect. For example, a defect with a severity ranking of 1 might only be a typo or some small cosmetic issue, while a story with a severity ranking of 5 might be corrupted or lost data, or a system that is entirely unavailable.

The table below provides Lant’s example wording for ranking a defect’s severity:

5

Data loss, data corruption or system unavailable

4

Important functionality is unavailable with no workaround

3

Important functionality is unavailable but has a reasonable workaround

2

Secondary functionality is unavailable but has a reasonable workaround

1

Cosmetic issues or some functionality unavailable but has a simple workaround

Once again, we need a color-coded matrix and associated key to help us address each priority color. Below you will find Lant’s original color matrix:

Similar to our story matrix, we adjusted the defect priority matrix colors to look like this:

And here is Lant’s decision-making key for defects:

As a result of these new ranking frameworks, my team was able to work our way through a long, seemingly never-ending list of defects that were rarely being addressed. I’m now feeling better about the quality of my product from both a defect management and a new feature prioritization perspective. Our process is much more streamlined, and I am able to quickly throw ideas and defects into unranked buckets before I properly rank and prioritize them. This way, I never lose an idea if I am too busy working on something else.

Screen_Shot_2016-04-22_at_1_39_14_AM.png

And that’s it! I’m still iterating on this process myself, so I would love to hear if you are able to apply a similar process to your own team using new methods or tools other than the ones mentioned here.

Good luck!

About Christopher Davis
ChrisDavis-headshot_8-3-2013_500x500Chris is a Product Manager at Bandsintown, Product Expert in Residence at General Assembly, and a writer and editor for music magazines including DJ Times, ClubWorld and The Music & Sound Retailer. Additionally, Chris is a life-long percussionist, DJ, and a music producer that has performed in wind symphonies, the Atlanta Falcons drumline, and various bands. He is also a graduate of The University of Georgia and is a huge college football fan. Find him on Twitter and across the internet at @chriskdavis.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

In Product Management, soft skills lead to hard lessons

Guest Post by: Jince Kuruvilla (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Rishi Kumar]

v2[1]

Regret, sorrow, disappointment – not all team check-ins and spec reviews end like this, but for a while, most of mine did. I mean, I was nearly a year into my first real Product Management position and I still didn’t feel like I knew what I was doing! Sure, I had spent the majority of my career as a UX Designer, and when I transitioned into a Product Manager role, I made sure to work tirelessly and develop “hard” PM skills like market analyzation, feature prioritization, a command of AGILE, etc. I knew how to build successful products and how to communicate & collaborate effectively, so why was I having such a hard time being a Product Manager?

Well, it took me a while (and a lot of long conversations with my mentor, Rishi Kumar) to realize that my brute force technique wasn’t working. In my quest to learn so many hard PM skills, I seemed to have missed the importance of learning the softer side of being a PM – building and maintaining close relationships with your team.

calculatedistance[1]It wasn’t like we actively distrusted each other – more so the fact that we rarely saw each other in person – we had a wee 4,225 mile gap between myself in Brooklyn, NY and my engineers in Poland. Don’t get me wrong, we communicated pretty frequently –  emails, Skype chats, and a few weekly video chats. Technically, we were in sync and producing great work but the problem was that the great work never aligned: I’d make great specs and document great features, but my engineers felt uncomfortable asking questions and being overly critical of the specs while I felt embarrassed to ask about technical issues, resulting in features being built that were far from the specifications.

My mentor, Rishi, took time to hear me out and help dissect my issue. If anyone could help, it was him; he also worked with a remote team in a different time zone—he could empathize and understand my situation. Rishi even went on to give a fantastic presentation about working remotely to the Product Group! In his talk, he discusses concepts like communication equality, the importance of making personal connections, and most importantly, building trust through transparency/visibility. Rishi helped me realize that in order to address these issues I was having, I needed to take a different approach to my work relationships. With his guidance (and the nuggets of wisdom that the other mentors in the program shared on the youtube presentations), I set out with a new approach to building greater trust and camaraderie within my team:

  1. I established a strict daily “standup” meeting.

    My Polish teammates and I  communicated through email and skype messages constantly, so initially, there never felt like a real need for a standup. A few weeks after starting a daily standup, however, I could see why they’re such a crucial element in Product teams – the daily standup allowed me to have face-time with my coworkers and have a chance to interact informally with each other. The daily standups, though redundant at times, helped us grow closer by formally creating space for conversations to occur and for viewpoints to be explained.

  1. I set out to share my raw, unfinished work with my teammates.

    I will admit that I have a tendency to be a perfectionist. I’m no stranger to sharing my works in progress with my fellow PM’s but sharing with developers and engineers meant being able to explain every little technical detail – I couldn’t “paint in broad strokes,” is what I had initially thought.

    Work_In_Progress[1]I experimented by having a few collaborative work-sessions with my developers over Skype – I showed them sketches and very rough concepts and ideas to help them understand my point-of-view but also to give them a chance to make suggestions and iterate together. At first, the conversations were laborious and slid very far onto the technical side of things, but we soon found our footing and were able to have both high-level “broad strokes” conversations alongside the technical/implementation questions.

    Through this process, I ended up becoming quite comfortable with the phrase “I don’t know. I’ll look into that.” I was initially afraid that showing this vulnerability would tarnish what respect they had for me, but soon found that they respected me even more for sharing my process and unfinished ideas. Not only did it give us a chance to brainstorm and ideate together, it allowed my team to see a side of our process that they hadn’t seen before.

    Soon after, my teammates would set up meetings with me to show me their own unfinished work: rough builds of features they were working on. Product demos were starting to happen nearly daily (instead of once or twice a week, previously) which led to greater transparency and greater shared ownership in our product development process..

  1. I set out to talk about anything but work .
    20151201182321-business-people-drinking-coffee-talking-networking[1]
    As pedestrian as it may sound, this was probably the biggest takeaway for me. It’s easy for me to socialize with my co-workers in my Brooklyn office since we spend so much (physical) time with each other – but my teammates in Poland don’t really get to see that “social-Jince” since most of our communication was work-related.

    To counter this, I set out with a peculiar strategy – I set up calendar invites as reminders to myself to have non-work-related conversations with my Polish counterparts – conversations to check up on their families, their hobbies, etc. As embarrassing as it sounds, the calendar invites helped tremendously in making sure I had these conversations.

    I learned so much about my coworkers and what made each of them tick. It all eventually helped me understand how best to communicate with them at work. I knew that Piotr, with his design interest, could understand when i talked about functionality in broad, visual strokes, while Michal was less interested in the visual side and wanted to know what the user goals were and the rationale for every single UI element and product decision. These learnings led to more efficient work-related communication between all of us. 

I was skeptical at first, but focusing on building these soft skills of navigating and forming camaraderie with my remote co-workers has been, without a shadow of a doubt, one of the greatest lessons I’ve ever learned in my Product Management career. The results speak for themselves: after about a month of implementing these new tactics, team morale increased tremendously and we hit our stride. Spec meetings and daily standups were no long foreboding events, but events that our team looked forward to.

I’m happy to share that our team’s friendship has evolved to become the foundation of our working relationship – our interpersonal connections have helped us successfully navigate tense product conversations and establish a wealth of empathy for each other’s’ roles and responsibilities.

The soft skills that the The Product Mentor program drove me to learn have lead to hard lessons; most of which come back to a simple idea: in order to build great products, you need to have a great team — in order to have a great team, you have to work on building trust, camaraderie and a sense of belonging. Only then will you and your team be able to produce the best possible work possible. Take it from me—I learned these soft skills the hard way!

 

About Jince Kuruvilla
JinceKuruvillaJince is a Product Manager with a background in User Experience and Design Strategy. He’s carved a career for himself working on products that inspire and empower people – everything from physical products to digital experiences. Ask him about spices, social entrepreneurship, and hip hop trivia — you’re sure to get an earful!

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

The Worst Nightmare of Any Product Manager

Guest Post by: Liel Aharon (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Felix Sargent]

adelorme_11[1]

At the end of 2015 I was in the worst nightmare of any Product Manager.

I had a strong roadmap, clear goals and a vision for the product. The team had been working for almost a year and had a huge amount of code under their belts. We would regularly meet to discuss the features required, what the customers expected. We were making great progress. But just because it was a lot of code doesn’t mean it worked. In fact, our tests regularly failed. The relationship between QA and Engineering was bordering on food fights, and we’d only achieved half of our requirements. A production release was a distant vision.

As we were getting closer to the end of the year, my senior vice president called me in, to review our progress against our goals. He asked me to provide a status of where we stand, and wanted to make sure we are on track to deliver on time and get our bonus.

Oh crap, no way we could deliver on time I thought to myself.
How did I get here?

It wasn’t one thing. There were a variety of different problems, and symptoms. We’d made great code. We had good production standards. We were Agile, with daily standups, two week sprints and detailed estimations. We were testing our code. What did we lack?

Focus.

I thought if we’re already doing one thing we might as well also another, or just fix this thing as well. When we were working on creating the edit permissions group for apps, we also decided to work on the internal permissions that will be used by the team that supports the Appstore. Similar, right? Should be an easy fix. Wrong.

I’m not a technical Product Manager. I knew that I couldn’t look into the code to see that our engineers had built what I was looking for. I felt I had to wait until a feature built out before I could give my feedback.

We were doing Agile. We had a daily standup, sprints and estimations. But with nothing to ship, were we? Did it matter? Was it my fault?

My Senior Vice President needed an answer. More “Context and Direction”. We needed to deliver in three months. What could we salvage?

“From now on, only our most critical stories will be completed as part of V 1.0.0.”

If we were going to ship in three months, we had to figure out what we were shipping. Two sleepless nights, eight shots of espresso and one bottle of wine later, I worked with the team to have a plan. We were going to focus on making the most crucial api call to create apps work, the rest we decided to change through direct db access at first.

Once we were able to define what  V1.0.0 was it was easier to break down the issues into small stories. Prioritizing between stories got easier, because we know what they were.  The result of it were clearly scoped versions, that last about 2 weeks for development, testing, and validation.

When the team started working in shorter cycles, testing was simpler, and they could get my feedback quicker. I had the confidence to test new features to make sure we are building in the right direction, and engineers felt on track.

Finally I was able to breath.

After going from a long development process to a shorter cycle, we have managed to resolve our most glaring problems. We managed to decrease each dev-test-release cycle from being months to 2 weeks. Was the problem Agile? Or were we just not doing it right? It’s easy to confuse the rituals of Agile with actually getting things done.

If you are having similar problems with your development process I highly advise you to analyze the reasons to them, starting with an honest answer to the question – is your process actually solving your problems?

 

About Liel Aharon
LielAharonLiel (pronounced as Lee-L’) is a Product Manager at MediaMath, the marketing operating system, and is the Product Owner of the company’s Appstore. Before that she held multiple positions in Fin-Tech companies in Israel as Associate Product Manager, Project Manager and QA Engineer. Her Computer Science with a major in Entrepreneurship along with her past experience is giving her a unique point of view with a let’s get this done attitude. When not working Liel can be found adoring her Boston Terrier puppy, or working on another home cooked meal with a paired cocktail.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Reconciling Product Management and Product Leadership

Guest Post by: Lamia Benhaddou (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Amanda Ralph]

A Product manager tasked to lead and manage her team while still providing product management capabilities; that was my position when I was selected to be part of the product mentorship program and paired with Amanda Ralph, my new mentor. Amanda had 18 years of product management experience and was able to clearly foresee the obstacles I might encounter in my new role.

We started by defining the objectives I wanted to achieve over the course of my 6 months in the product mentor program, an important exercise at the beginning of any mentor partnership. I identified with my mentor Amanda, the areas that I needed to support in order to still deliver product management capabilities not only as a product manager but as a team; a team which I now lead.  

Indeed the role of a product leader is different to that of a product manager. A product leader not only has to manage products but also to guide and direct the overall product strategy and team, and ensure that products are delivered to market.

If you are stepping in a new role involving more responsibilities you will find in this article 3 essential points to consider for a smoother career transition.

Restructuring the Team

When thinking about my new role and what needs to be delivered, I establish that the team needs to be restructured in order to better align and deliver products to market and, to enable me to consolidate my new role as both product manager and people leader. In addition to restructuring the team I also need to focus on empowering and enabling my team to take greater ownership and accountability for managing and delivering the products.

Here are the key points to take into account when defining the new structure and capabilities of the team:

The 4 steps to empower the team

1/ Draw a mind map of all the product management capabilities that I am delivering as a product manager and identify the ones that can be transferred to the team.

2/ Assess the capabilities of the team by meeting every team member individually to understand both their capabilities and aspirations. In these meetings, I try to understand the current challenges each individual faces and how they can grow in this team.

3/ Do a matrix of skills to map team member skills and identify development opportunities. Identify both formal training opportunities and projects which give team members the chance to apply newly acquired skills in their day-to-day activities and develop their role.  

4/ Establish a training program for every team member or by team functions. This training set can be composed of workshops where I can transfer my product management knowledge (e.g. how to write user stories, stakeholder management, how to define value proposition). Allow for workshops where team members from other teams are invited to give a presentation (e.g., basics of project management by a project manager, etc.)

Facilitating better team collaboration

With less time on hand, it is important to develop procedures with the team that will fast track collaboration and delivery. Ensure that the communication between designers, developers and producers is optimal. The Scrum ceremonies (Sprint planning, Standups, etc.) and kick-off meetings of a new project are a good way to ensure that. Holding regular Agile retrospectives can be very useful in this regard and allow a safer communication to happen within the team.

At the end of the day, your job is to ship the right product to the users. I encourage then the team to have a greater understanding of the users. This can be done for example by involving the developers and product owners in the user research, the wireframes assessment and the usability testing sessions.  

Resource management

A new leadership role is also a good opportunity to assess and evaluate whether you have the right skill sets and resource capacity in your team.  It is impractical to continue to do your old role as well as lead the team. So you need to assess whether there are opportunities within the team for individuals to step up and take on more responsibility or whether you need to bring additional resources into the team.

Stakeholder engagement

By taking on more responsibilities, I need to demonstrate leadership and gain the confidence and trust of my stakeholders.

Engage effectively the stakeholders

The product manager is the link between the internal/external stakeholders and the team. Identify your stakeholders, analyse and engage with them effectively by using the power grid by Roman Pichler, which Amanda shared with me. This is a relative quick exercise and the matrix can be adjusted over time. With this matrix set, I can then for each product save time by inviting the right people to the discussion.

https://lh4.googleusercontent.com/AYp1eOFT4Y59U-QCvlf0zunpoEonY5ip23vS9HYNKZGYGI4JtuWkbmTu9F0KfI-uzUoOk7Fuo00D2CYuWTikMlhUegLaZNHXxfXApTQHSfPK5ExthkNdgrl7HTs5vo71l4WkGAtI

Draft procedures to get commitment

To ensure ongoing and active collaboration with stakeholders, it is important that procedures are defined and created together. For this, I define with my team the areas that can be improved, for example, handling Business As Usual requests which can be a source of frustration if they are not handled properly.

We start by drafting the ideal process with the producers and then refine them with key stakeholders’ input. At the end, we map a process that everyone can agree on. We implement then this procedure and iterate on it if necessary.

Educate stakeholders

Product management can be quite a new thing for businesses, especially technical product management. Some colleagues can be confused on what to expect from a technical product manager.

“Brown Bag” lunches can be a useful tactic to engage stakeholders and the wider business. They provide an opportunity to share your knowledge on product management capabilities (product planning, product strategy, UX lean methodology, product roadmap, etc.). This provides more clarity to stakeholders about what product management is, and where and how their expertise will be needed in the product development lifecycle.

Organize a product meeting

To get buy-in, you need to create a circle of trust with your stakeholders. For this to occur they need to be brought into the product development process. Establishing regular product meetings with key stakeholders to discuss current product roadmap and priorities is a great way to keep the business engaged and informed. As Rian Van Der Merwe explains it in Making it Right, these meetings enable us (managers and stakeholders) to ensure we are still working on the most important things. If something more important comes up, we prioritize it higher in the roadmap, and something else has to shift down; if stakeholders agree with the direction, we do nothing. If a new opportunity arises we can ask ourselves, “Is this the most important feature we are working on right now? Or is this something we should work on next? If so, what moves down the priority list?”

Monitor your productivity

When taking on more responsibilities, it is also important to review your current productivity. You need to constantly assess your physical, emotional and mental energy to be able to deliver against requirements without reaching the burnout.

I start every week by listing what I need to achieve. Throughout the day I use the Pomodoro technique to keep myself focused. One tip from Amanda is to block your calendar for 2 hours every day, especially in the morning where you know that you can achieve important tasks and let stakeholders invite you to meetings in the afternoon. Meetings don’t need to be conducted all the time in a meeting room. A walking meeting can be a good way to engage with stakeholders and keep their attention on the subject.

Setting time aside for yourself remains a critical part of the process. To keep balance I try to always do at least one physical activity per week. We also gather with a few colleagues to practice 10 to 15 minutes of guided meditation after lunch. Mindfulness increases focus, improves our ability to reduce stress, enhances clarity of mind and leadership effectiveness. The Search Inside yourself book provides a great practical introduction to mindful leadership.

Hopefully this list of tips will help you to find your way to transition from a Product Manager to a Product Leader and manage the balance of ‘doing’ (developing and shipping products) and ‘leading’ (day to day people and product portfolio leadership).

 

About Lamia Benhaddou
Lamia BenhaddouStarting as a web developer, Lamia’s journey through the digital space has come full circle, from managing large scale websites to coaching teams to adopt a more efficient product development with Scrum, and now in the education space with a particular emphasis on lean product management.

Lamia has also worked in a variety of contexts such as global organisations, startups, NGOs and is now the head of digital product for higher education provider Laureate Australia, bringing a UX focus to all digital sides of the business.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

User Onboarding in Enterprise SaaS #prodmgmt

Guest Post by: Prakhar Agarwal (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Sara Varki]

saas[1]Introduction

Nowadays, we all consume applications and platforms (software) over the web. “Software installation” is quickly becoming an old concept, especially for end users. Be it documents, photos, marketing, sales, or product, it’s all moving away from installing software on an operating system to just creating an account for a web-based service. This is the world of Software-as-a-Service (SaaS). Growth of SaaS companies in recent years has been explosive. Like all companies, these SaaS companies face several challenges broadly defined by the following three questions (along with the associated function of the company):

  • How do I get more visitors to our service and get them to sign-up? (Marketing)

  • How do I get more users to return to our service? (Product)

  • How do I get returning users to become customers? (Sales)

Customer Acquisition Cost (CAC), Churn, and LIfetime Value (LTV) are the KPIs used to check the health of a SaaS business. We track the funnel, calculate conversion rates, and search for repeatable patterns to make our revenue numbers. To be a successful company, the value proposition should be easy to understand, the product should be easy to use, and it should be easy to buy. If any of those three things falls short, the company fails. In my opinion, it can all be summed into Customer Experience. A blurb from Wikipedia [1]:

Hand writing Smiley on the Customer  - Customer Retention Customer experience (CX) is the product of an interaction between an organization and a customer over the duration of their relationship. This interaction includes a customer’s attraction, awareness, discovery, cultivation, advocacy and purchase and use of a service.

In this article, we will briefly explore one part of these interactions, specifically between the user and product itself. An effectively designed product will solve one or many user problems. A key element in successful user adoption is User Onboarding. While it sounds simple, it is the most critical and often the most ignored part of the product development cycle. We will explore this subject in the context of Enterprise SaaS where a solution is expected to solve multiple pains and generally has a lot of moving parts and complex workflows. We will discuss why onboarding should be a priority and how to do it correctly.

Why User Onboarding

Everything is about people.

People use things, people pay for things.
People require services, people provide services.
People use products, people develop products.

In all of the grand things in life, people are the only constant ingredient. So, it’s imperative that the experiences people have are delightful and memorable. All the functions in an organization should focus on this metric.

Above statements are a true reflection of my way of thinking about businesses as is evident from my LinkedIn summary.

1480302922795[1]Providing a great experience on all user touchpoints should be part of the core of all functions in a company. Specifically, user onboarding for the products should not be a project or a feature that gets released but then is not looked at for months or years; rather, it should be an element that is always evolving.

The essence of user onboarding is how quickly a product can provide value to the user by helping them solve their problem and getting them to the “wow” moment. For users of Enterprise SaaS products, it is critical that they feel in control of achieving their goals. There are several reasons why User Onboarding is so important:

  1. Quick Adoption and Frequent Releases: Traditionally, users are accustomed to locally-installed enterprise software, also known as shipped software. This software is not updated frequently and thereby a user gets a lot of time to become comfortable with it. Ultimately, such software gets very sticky and the companies reap rewards for a long time. So, these users bring a lot of baggage with them when they are trying to adopt new SaaS products. Therefore, it is important that the initial transition to the new SaaS paradigm is smooth and quick. The Unique Selling Point (USP) of SaaS products is mobility for users and an abstraction of several moving components. Successfully delivering such an abstraction requires replacing existing workflows while eliminating barriers. Also, this delivery model provides an opportunity for companies to introduce improvements and features more frequently. Extra care should be taken in such shorter release cycles to avoid disruption to users’ current workflows.

  1. Competition: Since SaaS products are now becoming mainstream, users have a lot of options and the cost of switching to a new product is relatively low. For the companies, the cost of customer acquisition is increasing since there is more competition. So, products can’t really win purely on functionality; achieving desired stickiness with their users will require a lot more. The usability of a product and onboarding experience is quickly becoming the differentiating factor. Consumer products were the first ones to take advantage of these notions and with a strong user-base overlap between consumer products and SaaS products, it was only a matter of time when users felt that business software needs to match the experience of non-business software, also known as “Consumerization of IT”.

  1. Lifetime Value: The goal of a great user onboarding for a SaaS product is to allow a user to extract maximum value in shortest time possible so that they become repeat users and potentially paid customers. Often, a user would be willing to pay for a premium service if it offers great onboarding experience and either eliminates a steep learning curve or manages it well. Bad user onboarding is a sure way to alienate potential customers. A user will try a product, and if they can’t reach to the value quickly, they will leave and never come back. In an Enterprise SaaS company, the sales cycles are short and the payback period is long. And, there’s always a risk of churn. So, the company should invest in right onboarding to reduce their churn and thereby increase their customer lifetime value.

Now that we understand why user onboarding is so critical to SaaS world, let’s see how it can be done right and few mistakes to be avoided.

How To Do Enterprise SaaS User Onboarding

AAEAAQAAAAAAAAw9AAAAJDdmZmFjZjNmLTJkNDItNDliMi05ZDI2LWViYWEwNGQxMTk3NA[1]One quick search about “SaaS Onboarding” will show thousands of results for books and articles advocating various methods to improve the experience for a new user. All these methods and ideologies have one thing in common – “reduce and control friction in the product”. Even with all the advice, the products that we develop and use on a daily basis have great visual appeal but less thought out user journey. In the last ten years, the advancement in application frameworks has had a significant impact on the visual layer of Enterprise SaaS products. The development is so quick that there’s a new framework every six months or so.

On the other hand, there has been less emphasis on measuring user perception and behavior and improving the onboarding based on those insights:

  1. Why did this user not use the product after signing-up?

  2. How much time does it take for the users to reach the first milestone?

  3. What percentage of the expected first-interaction behavior is the user completing?

  4. Are there any dead ends in the workflow that prevent the users to get early wins?

All these are important questions for a product manager to be able to improve the product adoption with first-time users.

Here’s a short framework to kickstart the improvement of user onboarding (and entire product in general) for Enterprise SaaS:

  1. Start from the end goal and work backward: Understand the user and their specific problems, and then design the product and market the value proposition. This way of thinking is getting standardized via the disciplines of user experience design and lays the groundwork for designing user onboarding. Result: With the user research done properly, the user onboarding will cater to the acute problems that a user faces while solving their pains and this will lead to a simple and focused product.

  1. Convey the value proposition clearly: People’s attention span is getting shorter; providing a clear value proposition goes a long way to create excitement and motivate a user to try the product. Correct messaging is a critical first step of onboarding. Find the content that led current users to the “aha” moment. Work with the sales team to learn what potential customers perceive as the value proposition. Then work with the marketing team to make sure those nuggets are presented well to the visitors in all web and print material. Show the users the promised land. Result: Users will be motivated before trying the product.

  1. framework[1]Get them in the door: Once a user understands your value proposition, it’s important to keep that momentum going by getting them into the product as soon as possible. Design the sign-up process to be quick and let the user get an early win. For example, if the sign-up process requires collecting a lot of information, it’s better to collect the most critical items first and the remaining information as the user progresses in the product. Tie the collection of these nuggets with various product actions. Result: Users will not be overwhelmed and would give you more information as they use the product.

  1. Find conversion actions: Track all the user activity in your product to identify the actions that led a user to become a customer. Or, just watch the users use your product and see what they do to reach the main goal. If available, work with the sales team to participate in potential customers’ product evaluation process. There is a heavy component of product analytics in this part of user onboarding improvement and always reveals very interesting insights! For example, if one of the conversion milestones for a data analytics product is to enable an integration, find out how much time a user takes  to get to that step and the number of steps that lead to it. In other words, work with the product analytics team to understand the user journey. Result: This will help reduce CAC.

  1. Balance Friction: Using the insights above, improve the flow to let the users reach the conversion actions more quickly. Eliminate all the extraneous steps that are not strongly tied to the value of the product. Make the flow intuitive so that a user  This will reduce the time from first interaction to conversion actions. Provide relevant feedback to the user during their onboarding to establish the notions of security, reliability and fun, wherever applicable. It’s best for the users as they extract more value and feel more confident, and it’s great for the company as the product gets sticky with user’s each new win. Result: This will drive down the churn rate.

In summary:

  1. Create meaningful experiences that let users get to the value immediately and continually

  2. Include user onboarding in the foundation layer of product development and let the entire organization strive for improving the user experience.

  3. Anything we can do to make it easier for a customer to get started with the product, the better.

Great user onboarding facilitates problem solving and gets out of the way of a user!

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Managing Your Career and Yourself Like a Product

Guest Post by: Hansa Vagadiya (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Ladislav Bartos]

youaretheproduct_638[1]

Recently, I participated in a product management mentorship program run by The Product Mentor.

Ladislav Bartos, who was assigned to me as my inspirational mentor, has been working with me to further hone in on my product management skills. I have improved my stakeholder management techniques; learnt about service design thinking and enhanced my Google Analytics knowledge. But the most important thing the product mentorship can unconsciously provide, is guidance and support towards clarifying what your long term career goals are as a product manager.

Think of your product management career development as a new product that is going to be released into the market. You want to be the product that is useable, feasible and valuable to the target audience/customer ie you’re selling yourself as the solution to some specific company’s specific problem.

In product management you’re schooled to, identify who your customers are; identify a value proposition strategy and to persuade stakeholders of the vision you want to achieve. You can stand out from other product managers by applying these skills to yourself.

MVP of you

In product development, the minimum viable product (MVP) is a product which has just enough features to gather validated learning about the product and its continued development. If you are just starting out in your product management career it is important to look at where you fit in the market.

This is where you will need to do carry out market research and value proposition testing.

  1. Who is the target audience/segment/customer? (Which company should value the attributes you have to offer?)

  2. What problem are you solving? (What are the company’s problem you can help alleviate?)

  3. What product features can solve the problem? (What special skills and experience do you have?)

Release 2

Image result for product releaseNow that the MVP has been launched to the user – it is time to iterate and make improvements on the product based on customer feedback and lessons learned.

  1. How can you improve on a current feature? (What skills do you have that can be enhanced?)

  2. How can you further establish a competitive advantage in the market? (Do you want to have a competitive edge in having experience towards a particular business function? UX, Business or Technology focussed product manager?)

Tapping into a network of people that have experience in product management and/or reading product management books/online resources will help you to answer these questions.

Release 3 (Pivot)

As a product, you have been available in the market for some time and have either succeeded in solving your target audience’s short term problem and/or are struggling to add any further value and you have decided to pivot. A pivot is a “structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.”[1

  • Is there another target audience that is better satisfied with the product you have? (What other company could benefit from your skills and experiences?)

  • Does the value proposition need tweaking or changing completely? (Are there other industry/product types that interest you? Ecommerce? Publishing? etc)

  • Are your product features not solving the user’s problem? (Are your skills and experiences no longer suited towards the role you are currently in?)

When deciding to pivot it is good to think about these questions beforehand to evaluate the costs and benefits of pivoting.

Do you have a Product Roadmap? 

As a product manager the management of your product roadmap is the same as the management of yourself and your career.

What is your product vision? What are your goals? What are the metrics that will determine if your goals have been achieved? (Where do you want to be in the next 5 – 10 years? What industry excited you and has potential growth? What skills do you want to develop by x period of time and what are the success metrics?)

Without having a product roadmap, it is difficult to know what stage you are in your product lifecycle. It’s a question a lot of budding product managers face. Do you keep iterating on your product after the initial MVP launch or is it time to pivot?

As I come to the end of the mentorship program I would like to advise all other budding product managers to create your own product roadmaps. You’ll be surprised at how much it can help you answer your own questions.

qlm5ymb2nxax56705112014_700x300[1]

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

How Communicating More Can Help You Succeed as a Product Manager

Guest Post by: Lonnie Rosenbaum (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Marc Abraham]

many-speech-bubbles-GEOFFREY-JAMES[1]

Sharing product information within your company is one of the most valuable things you can do as a product manager. Whether it’s your plans (roadmap), feedback you’ve heard from users, product usage data (analytics), or posing questions — getting what you’re doing and thinking in front of a cross-departmental audience will provide you with input that helps you make better decisions and will help align others with the goals you’re looking to achieve.

Spreading info can also help other people be more effective in their roles as they’ll be able to better prepare for upcoming changes. It can get them excited about the direction of the product, and it can make it known across your organization that you’re a person to bring questions or feedback to — opening up more lines of communication to help inform your thinking.

Tactics

funwheelswingin[1]Hold a recurring meeting once per month that gets you in front of a cross-departmental audience

  • Invite people not only from Product & Tech, but also Support, Sales, Training, and any other relevant group.

  • Create slides to walk the audience through:

    • What’s been happening with the product (e.g., recap the last release, usage data)

    • What’s coming up soon (e.g., the next release)

    • Future thinking (e.g., distant roadmap possibilities)

    • Research initiatives (e.g., what problems about your users or business you’ve identified recently and their impact, what solutions might be viable, what you plan to learn about soon)

    • Competitive analysis (e.g., if you recently discovered a new competitor that you think would be valuable for others to know about, or if you want to highlight how a potential new feature could be a differentiator for your company’s solution vs. others)

  • Solicit feedback.

  • At the end, recap any next steps and actions.

While this might take you a few hours to prepare for each month, sharing information (ideally in an engaging way) is one of the most valuable things that can be done within a company, not only bringing info to others but also to you.

These sessions can also give people better insight into how you think and approach things as a product person, which is particularly valuable to stakeholders who you don’t work with on a regular basis. And it’s a way to take people on the journey of the product, showing where it’s been and where it’s heading, growing support and buy-in along the way.

stand out from the crowd

Sync with certain people in advance of this meeting to prepare material

  • Ask co-workers in Support about common user pitfalls and analyze Support case trends with them.

  • Ask co-workers in Sales and/or Business Development about common sticking points that prevent a deal from closing. (Or if your company is more Marketing-centric, sync with the Marketing team.)

  • Ask the appropriate people about why users stop using your product (i.e., cancellations / churn).

You’d ideally be able to see quantitative data on these topics, in addition to having conversations about them. Depending on how much detail is made available to you, it could also be useful to speak with some of the users who these topics relate to so that you can dig deeper into the reasons behind what they said to your co-workers (i.e., learning why something happened, instead of only what happened).

Example

The following is an example sequence of slides that you could use or adapt

  1. Intro / purpose of the meeting (state a goal of sharing information and identifying better solutions)

  2. Recap of last release

  3. Plan for next release

  4. Insight / question #1 (takeaways from recent research you did, a trend that you think is worth raising awareness for and getting feedback on, or some other topic you’d like to increase visibility on)

  5. Insight / question #2

  6. Questions / feedback (while you should welcome questions or feedback throughout the meeting, it’s a good idea to dedicate a couple of minutes at the end for anything not already covered)

Tips

Don’t feel like you need to do all of the above from the start

  • You can start simple with a small audience and short list of topics to get feedback and adapt for the next session, gradually inviting more people.

  • The most important thing is to get started with something, and be open with participants about how you want them to get value out of it and that you welcome their feedback. Adjust the format over time to find what works best.

  • Aim for a 50-minute meeting. If you find that 50 minutes isn’t enough, trim some content for the next time so that you can get it done in 50 minutes. If you engage the participants (e.g., by asking some to help prepare material in advance, and by inviting questions/feedback during), this will feel like a short meeting packed with insights and takeaways for everyone.

0155351_PE313641_S5[1]Frame the meeting in the right way

  • It’s not meant to be a collaborative prioritization session. Some open discussion among attendees is great, but it’s not a debate on what to work on.

  • You’re sharing information and believe that everyone benefits from hearing insights, both from you and others.

In general, respond quickly to whatever comes your way

  • Even if you don’t have an answer that someone is hoping for (e.g., if your answer is that it’s going to be a while longer until their concern is addressed in the product), getting back to people in a timely manner gives them reason to reach out to you again in the future, which can provide you with valuable intel.

  • Sometimes you might pass someone’s question to someone else who is better suited to answer it, which is fine. Whether you or someone else answers it, you helped get the answer.

Recap

Communication is a two-way street. When you share information with others, they’re more likely to share information with you.

Having a steady flow of communication with a group of people from across your organization enables you to test ideas sooner, hear feedback sooner, and make ideas better — resulting in better product decisions and benefits for both users and the business.

Overall, communication can be a big factor in a product manager’s success, both with a product’s success and also the product manager’s career trajectory. Seize the opportunity to spread information and to learn from others, and position yourself as a go-to person in your company.

[Note: This article didn’t touch on external communication, such as with users, partners, or vendors, which is worthy of its own writeup.]

About Lonnie Rosenbaum
LonnieRosenbaumPicture-Choice2Lonnie is a product manager with experience in both web and mobile, currently working at Booker on their native mobile apps. Previously, he held product roles at three other technology companies, two of which he co-founded. Lonnie blogs about product and entrepreneurship at http://lonnierosenbaum.com.

 

 

 

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Driving Product Growth with Customer Interviews in 20 days

Guest Post by: Jeffrey Owens (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Chris Butler]

customersRESIZEDXXX-56ef5043[1]

In the startup mindset of move fast and break things (thanks Mark Zuckerberg), often times customer interviews and getting to know how users interact with your application fall behind. At SpotHero, we have recently graduated from the “startup” product style of push as many things through as possible to a more mature and calculated product lifecycle. Product vision, no longer determined by emotion, rather derived from sound metrics – is executed through the product roadmap, with clear and measurable goals in mind.

Determining what goes into your product roadmap to execute on this vision can be boiled down to two things: quantitative and qualitative research. From a planning perspective, quantitative research and feedback is pretty straight-forward – note: I didn’t say easy. Ensure all correct funnels and events are being tracked, analyze, and pull out key trends (to over-simplify).

The “art” of determining the product roadmap comes through qualitative research. Being able to pull the pain, motivations, problems and reasonings behind every user interaction in the application and finding tangible solutions to these problems is both critical and challenging.

Knowing minimal amounts of what was involved in customer interviews and gathering qualitative feedback, Chris Butler, my mentor and friend pointed me toward the Jobs-to-be-Done (JTBD) methodology. If you’re not familiar you can find it here: JTBD Interview Structure

Like Newton’s first law of motion – an object at rest will stay at rest – often the hardest part is finding where to start, and then actually starting. Personally, I have found it easiest to put together a quick project (product) plan that lays out clear goals with target dates, helping me reach towards a goal. The 20 day plan begins here:

Image result for plan

Day 1: Create User Segments

Creating users segments is the act of defining groups of customers that use your application, usually based on purchasing behaviors. After much deliberation, I eventually narrowed down my user segments from 6 to a more manageable 3. The process was simple – find the majority users and optimize for them. I found the other segments I created were around edge cases, which ultimately would be uncovered in talking to the primary users.

  1. Segment 1 – Users who have purchased monthly parking through SpotHero and still parked

  2. Segment 2 – Users who purchased monthly parking through SpotHero and cancelled

  3. Segment 3 – Considered purchasing, but didn’t

  4. Segment 4 – Users who started purchasing monthly through SpotHero and decided to stop

  5. Segment 5 – Users who are thinking of purchasing monthly parking, don’t know about SpotHero

  6. Segment 6 – People who buy enough daily parking to make the switch to monthly parking make sense

Day 2-3: Communication Plans for Segments

  1. Segment 1 – Pull list of users from database and offer customers $30 off future monthly purchase in order to have a 15-20 minute conversation with us.

  2. Segment 2 – Pull list of users from database and offer customers a $25 amazon gift card in exchange for a 15-20 minute conversation with us.

  3. Segment 3 – Using our analytics tool find users who dropped off in our sales funnel before purchasing, and reach out offering a $25 amazon gift card to have a 15-20 minute conversation with us.

Image result for budget

Day 4: Determining Budget

Of all the things, this one was the most unclear to me. I wasn’t sure how to get the conversation started, and when I did, it never really went anywhere. To resolve this, I did three things

  1. Pulled numbers on the impact of monthly parking for the company’s GMV

    1. This shows the value of reaching out to customers and justifies the cost for providing credit or some sort of gift card.

  2. Determine how many users I needed to talk to in order to reach qualitative significance

    1. 4-7 users per segment will get you all the information you need. Usually after 1-2 conversations, any glaring needs become apparent. Conversations 3-7 confirm and provide additional insights.

  3. Proposed number value of how much each outreach would cost

    1. Segment 1 – $30 in monthly credit

    2. Segment 2 – $25 Amazon gift card

    3. Recording Software – $10

    4. Total Budget – $395

Day 5-7: Scripts for Interviews

Simultaneously with budgeting, I started building the scripts for the customer interviews using the recommended JTBD framework. The general framework I followed was:

  1. Introductions – get to know the customer’s background

  2. Point-of-Purchase – bring them back to the moment they purchased

  3. Finding first thought – what made they want to make the purchase

  4. Building Considerations – what were all the options they explored to solve the problem

  5. Searching – what was their experience looking for monthly parking with us

  6. Booking – what was their experience like when booking

  7. Post-Purchase – what was their experience after purchasing parking with us

    1. Cancellation Recap (if applicable) – what caused them to cancel their reservation

  8. General Questions – allow them to give feedback and ask questions

Day 7-17: Getting People on the Phone

Getting people on the phone was easier than I thought – once there was an incentive. I had originally tried outreach to customers to get on the phone without an incentive, and did not get a single person to email back. Once I introduced and incentive, I was amazed by how many people want to talk for $30 off parking/$25 dollar Amazon gift card. Beyond the expected cancellations and rescheduling, I was able to get my goal of 5-7 users per segment.

Recording the Interviews

Image result for recordingFirst thing to lay out – record your interviews! I cannot iterate this enough. Not only can others in the organization listen to these interviews, but taking notes during the conversation takes away from the interview and makes the interview very choppy as you scramble to write down everything the customer says.

During the interview, I found it was good to stick to the script as overall architecture and gave good reference points to go back to, but the most useful product information came from the tangents or stories that occurred only through natural conversation. The script should act as a guide, not the thing you read to customers, get their response and move on. Don’t be afraid to go into rabbit holes or pry a little more. Know when you’ve gone too far, and reference back to your script to bring the conversation back.

Day 18-19: Reviewing Feedback and Building Roadmap

By the 2nd conversation you’ll notice hints of trends and by the 3rd or 4th conversation you will be able to confirm. Even if you product is “flawless” – which it isn’t – customers (or all to often, investors) will find issues with it. The key is to listen for their problems and not their solutions. Chris taught me a great prioritization technique through questions:

  1. How much time do users spend on this problem or trying to solve this problem?

  2. How frequent do users run into this problem?

  3. What’s the impact of this problem?

  4. Will this problem stop users from using your product?

  5. Would a solution for this problem drastically change consumer behavior?

Answering these questions helps you put an apples-to-apples comparison against all the feedback you get from customers. A good equation for determining priority (higher the number, the higher the priority):

# times occurs * seconds it takes customer to solve + 100 if deters user = significance

The output will give you a list of problems in priority. You still need to determine if these can be solved with or without product solutions.

Wrapping it up

As you’re looking at your product roadmap, it’s important to make sure those solutions being built to achieve this roadmap are being built for the users of your product. I DO NOT promote the product roadmap being a list of static features that solves the problems. Rather, the roadmap should be a nimble document that lists out the problems you plan to solve for customers in priority order.

Customer needs change, and what you think is the most important today, will not be the same importance 1 month out, certainly not 3 months out. Set expectations within your organization that the product culture and roadmap will be to solve the biggest problems currently facing your customers. I challenge you to go no further than 3 months out and to always be gathering customer feedback both quantitative and qualitative to make a product that best solves your customer’s current problems.

Image result for feedback

Afterward

With all the above being said – we don’t work in a vacuum. Things come up, priorities change, and ultimately leads to many reasons why it won’t get done or can’t get done in 20 days.

Here are some things that got in the way for me, and how I worked around it.

Focus

Depending on your product culture, you may have more than one product you are focusing on. In my case it shifted many times throughout the twenty day period – our internal admin tool, monthly focus on web, external admin tool for parking operators to bugs and general run-the-business type features.

Key is to keep laser focus. It’s ok to miss a couple days, but similar to working out; the more days you miss, the harder it is to return. Be transparent with others in your organization about what you are doing, and don’t be afraid to tell people no or not right now. Make sure you are clear on the why and benefits what you are doing brings to the company.

Priorities

This was probably the hardest part for me. One week I was focusing on one tool, the next another. Each of them shifting in priority based on our internal and external needs. Each had its weight of being top priority.

We’re product managers for a reason – we can decipher the important from the unimportant (and hopefully everything in between). Only one thing can be top priority. Make sure if something is bumping it off top priority, it truly is top priority. Working on one-off projects that come up – i.e. fires or must-have features – generally don’t lead to moving the needle. Ask yourself if you’re firefighting or product managing. Avoid the former when at all possible.

Resources

This is a fun one. You go out, do all your research, and you hit a wall because there aren’t enough design resources, engineering resources, data science resource, whatever resources… you get the point.

Don’t let this stop you, and should certainly not be an excuse. Do what you can to get it to the point where you could hand it off, and if it never makes it there – that means there were other priorities that took it’s place. If this is your top priority, make it the top priority of your teams to get it done.

Remember, as the product manager, you represent the customers needs in every decision you make. The best way to arm yourself with what the customers are currently facing is to get in front of them and have a conversation. This not only builds brand loyalty, but ensures that your product will be solving real problems. You have the power to get in front of them – if you don’t, someone else will.

About Jeffrey Owens
JeffOwensProduct artisan, aspiring Entrepreneur; adventure and travel connoisseur. Jeff Owens is on a quest. Reach out to learn more.

 

 

 

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

How to transition from a Product Manager to a Product Leader

Guest Post by: Avinash Bajaj (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Nis Frome]

LeaderPatpitchaya[1]

So, you did whatever it took to become a Product Manager. Either you stumbled your way into product management, or you planned your way through. Whatever the case maybe, you are here now. You have done it.

Now, how do you transition yourself from a product guy to the product guy in your organization? How do you get others to respect the area that you love? How do you grow yourself and shape the organization around a product culture to make it more sustainable, more scalable and more efficient?

That is where I was – I was the first Product Manager in my organization, and now I have managed to carve a new Product Management discipline/department in the organizational structure.

Below are some of the takeaways of the experience that can hopefully help others who are at a similar transition phase of their lives:

(*Note: These are my personal experiences. These certainly do not mean this is the only way to follow, but hopefully these can help give guidelines on how some actions worked for me)

1.Challenge the Status Quo

Image result for status quo

If you want to become a Product Leader, act like one, NOW! When you are a Product Manager, your product is your business. But as a Product Leader, everything is your business. Just because things are a certain way doesn’t mean they should be. Ask questions – lots of them. Challenge assumptions and theories. Be bullish and aggressive in proposing product ideas, but at the same time, be stable and dependable to execute on those ideas. Don’t go into the position looking specifically to change everything. Give it a chance and try to understand why the ‘established’ practices exist. But don’t be afraid to challenge them and reconfigure them.

2.Be Entrepreneurial

entrepreneurial-growth-in-greener-industries-caption-image[1]I heard somewhere that great Product Leaders make great Entrepreneurs. I don’t know if that is true, but what has been true in my case is the attitude of “It’s better to ask forgiveness than permission”. As product managers, we often need to, have to, take decisions. But as Product Leaders, your decisions matter a lot more. There is more on the line. So we cannot be afraid to take hard calls if needed, and we have to be able to stand our ground and back ourselves when such a time comes.

Another aspect that is equally important for Product Leaders is the tendency to almost “walk” into chaotic, conventionally troublesome situations – that could mean standing up for a Product Manager colleague and taking the heat if something goes wrong, or, taking responsibility to solve a problem which you just became aware of, something that does not strictly lie within your product roadmap/portfolio.

3. Delegate and Support

As a Leader, you don’t have to take all decisions, in fact please don’t take all decisions. Learn to accept that people closest to certain topics are best to take those decisions. Your job is to lead and support those decisions – you don’t have to know 100% on the topic but you need to know enough to support the business case around those decisions. There is a reason you work with experts in areas that are not your expertise. As PMs you naturally learn to do this on a smaller scale, but as a product leader, you have to learn to inspire and teach PMs to get this awareness early on.

About Avinash Bajaj
AvinashBajajSean Echevarria is Head of Products by day and passionate about making a difference in the field of education.

 

 

 

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy