Prioritizing Product Features by ROI

Guest Post by: Roli Bhotika (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Zoe Feltham]

The most important lesson I learned in The Product Mentor program with Jeremy and Zoe was that Product Management has a language. That I spoke that language every day but my grammar needed some work. In more precise terms, my prioritization process factored in the things that it should, I just didn’t know how to translate it to ROI and present it logically. “We don’t do ROI assessments” was what I had been told at my company. I now know otherwise.

First we began by creating a data driven roadmap. This required separation and aggregation of data at various levels to assess the value of each feature and determine whether it could translate into opportunities.

Following this, we performed an ROI assessment on features that were already launched with a fresh set of eyes. The key here was to identify what I now know as “Key Performance Indicators” i.e. how do you know this idea is any good – how do you measure its potential? This was a critical step because it dictated the value a new idea brought to the business. Sometimes the value was in retaining business, sometimes in increasing it, sometimes there was no value at all – yet in the end some ideas remained. I was able to identify how my business measured the value of an idea and associate a $$ amount to it, positive,negative or zero – depending upon whether the cost of the idea outweighed its projected earnings. All ideas were rated on some additional key criteria apart from financial gains/losses such as: customer value, regulatory requirement, ease of adoption, whether it was a differentiator for us in the market or not. Because the reality was that, while sometimes there was no gain directly from an idea, there was a bigger driving force that was not financial at all on the surface but translated into a business need. The hardest step was assigning a weightage to each criteria in calculating a final ROI. This is where a regulatory mandate with no financial gain suddenly scoring a 5 on the regulatory requirement criteria shifted the overall priority for that idea even though there was no gain, only a cost to pursuing it. The ROI was finally a number but not a dollar amount. Just a ranking that factored in numerous criteria with specific weightage. And suddenly I knew why I had made a decision many months ago!

Finally – ROI wasn’t the final factor in making a schedule out of these ideas – it was also the ability to use pockets of available time across multiple teams and the desire to reach some key launches by specific industry events.

ROI calculation Template for a feature below:

Benefit

KPIs

Expected ADV (Average daily volume)

This is driver for my business area. It may be different for another industry.

Expected Weekly Profit

Differentiator in the industry (On a scale of 1-5)

These are key drivers/criteria for us to prioritize internally for our product. These can be expanded/changed to suit the product and its drivers.

Customer Service (On a Scale of 1-5)

Regulatory Ease (On a Scale of 1-5)

Ease of Adoption (On a Scale of 1-5)

Required For

Any mandates are noted here

Dependency on

Any added complexities/dependencies are noted here.

Average weekly cost

This factored in requirements, development, test cost based on the actual pay of an employee in that role

Total Earnings in 1 Week

Total Earnings in 1Y

The time window for an earnings calculation is really what might be relevant for the mindset of your company.

Earnings (On a scale of 1-5: under 500k, under 1 mil, under 5 mil, under 15 mil, Over 15 mil)

Note: here, features that were net loss, got assigned a score of zero.

Final ROI calculation

60% Earnings

15% Differentiation

10% Customer Service

10% Ease of Adoption

5% Regulatory Ease

The weightage above is only a sample, you must adjust it to find the right blend for your product and your current industry trend.

About Roli Bhotika 
5p10 - Roli 2As a part of Nasdaq’s US Options team, Roli Bhotika leads a team of Product managers, creates business roadmaps, sets the strategic direction, and makes prioritization decisions for ISE’s core options trading platform. She is focused on building and executing business strategy with a long term cutting edge vision for trading products. Roli enjoys keeping abreast of industry trends, concerns and market structure issues.

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

Starting at a New Company as a PM

Guest Post by: Jen Hau (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Ladislav Bartos]

Setting Yourself Up For Success

Product managers tend to be maximizers – always looking for the best possible choices and outcomes for their product. It’s no wonder then that product managers also tend to apply the same outlook to their own careers, often wondering whether there is another company or role that would be more optimal than the current.  Whether it’s the promise of more responsibilities, a higher salary, a riveting mission statement, or just simply a break from the same faces and routines of your current role, taking that new job is a step towards an unknown path.  Despite the fluidity of the industry – especially in New York, where it seems PMs have an average shelf life of about a year – there are surprisingly few resources dedicated to ensuring the success of an incoming product manager. Having just recently relived the experience of joining as a PM at a new company, I am living through this state myself and am seizing upon this opportunity to document my takeaways.  

Give yourself a break:  you won’t really “get it” for a while.

If you’re anything like me, you will be impatient to prove yourself. No matter what your prior accomplishments, your first day at a new company comes with a blank slate of achievements and some giant question marks. “Was this hire worth their salary? Will she meet our expectations? What will be the first thing she ships?”  These are questions – kitkat-snap[1]oftentimes imaginary – that can hang over your head, applying increasing pressure until you rush to make moves to demonstrate your worth.

I am fortunate enough to have access to Jeff Patton, the product thought leader, for periodic product coaching sessions. During my first call, he didn’t mince words on this topic: “Give yourself a break. You’ll be pretty useless for at least 3 months.”  And no – that’s not to say that you can’t start immediately providing value.  After all, there is a reason that they hired you.  It just means that it is normal to feel overwhelmed and to not feel everything “click” for a while, and that expecting more from yourself can lead you to make ill-informed decisions.  

Instead of rushing yourself into action, relish this time when you can view the industry, problem space, customers, or the product itself with a fresh set of eyes, as there will be plenty of time for you to get into the weeds later. If you seize this opportunity, your newness can be an advantage, rather than a handicap.

Clarify expectations with your manager.

It’s all well and good to take the requisite amount of time to onboard, but if this is not in line with what your manager expects, you need to address that right away. Depending on what you’re walking into, your manager may be impatient for you to start doing x, y, and z immediately. This isn’t malicious; it is human nature to forget what it was like to be a blank slate. (I can almost guarantee that in a year’s time, you yourself will likely forget what it was like before everything “clicked” into place.)  

I would encourage you to have an open conversation with your manager during your first week to go over the timeline of your onboarding. This timeline should be a week by week rundown of goals and objectives, and the types of activities that you will undertake to achieve those. If you do this exercise successfully, it will not only give you the room to  onboard properly, but it will also demonstrate that you are thoughtful and proactive in setting yourself up for success. Brownie points already earned!

Be shamelessly hungry.  You’ll need the information.

It would be nice if every company had an extensive onboarding program or bootcamp for their incoming PMs, supplemented with an impeccably organized company wiki and a series of check-ins so that you could ask any “dumb” question you will undoubtedly have. Those places may exist, but if your experience is anything like mine – especially if you’re all about that startup life – that rosy picture remains in the realm of fantasy.  

Even if your onboarding isn’t well thought-through, that is no excuse to sit around and be complacent.  The truth is that you will have to get yourself up to speed somehow so use what you have at your disposal.  Look around you – there is a treasure trove of information if you look hard enough, whether it is in shared folders, hung on the walls, or in people’s heads. Spend those hours hungrily digging through any shared Google Drive folders, and I guarantee you’ll learn something.  Establish a relationship with the veteran customer service team and I promise that you’ll gain a deeper perspective about your users and how they feel about not just your product but also about the company. Hack your way to knowledge when it’s not presented to you on a silver platter; it’ll pay off for you in the long run.

Coffee chats are your friend. It pays to know everyone.

As I mentioned above, getting to know people, regardless of their role or tenure at the company, is crucial for gaining knowledge when you start as a PM.  But there is also a bigger, overarching reason to establish these reasons, and that is simply because being known is better than being unknown.  Call it political if you want, but the reality is that our jobs as PMs is inherently political in that we have to weigh multiple interests, make tough decisions, and get people to believe in us (sometimes on nothing more than faith). It may not be the only way to do it, but I’ve found in my experience that it helps if people genuinely like you as a person.  

I’ve been around enough tech companies to know that PMs – and more broadly, the product team – are almost always perceived by the rest of the company as being surrounded by an aura of mystique surrounding them. Remember – the role of Product Manager is still a relatively new one in the grand scheme of things, and even more unfamiliar to those who  are new to the tech industry.  This lack of understanding and separation between PMs and the rest of the company can often lead to scapegoating when times get tough, as they’re bound to get at any startup. When sales plateau, it must be because the “product team isn’t really doing anything.” Or, when we turn down customer requests, it must be because the PMs are too lazy to pull off those “no-brainer quick wins.” This is why I am a huge believer in breaking down those walls by getting to know as many people across the company as I can, especially early on in my tenure. It’s much harder to point fingers when you empathize and understand the rigors of each person’s role, no matter what department they’re in.

Gain the trust and respect of your team.

The old joke about PMs is that we must move mountains to do the impossible, all while hiding the fact that we don’t actually hold any true power since none of the people we often work with report to us. The joke is true – and you should never forget it! To that end, you should seek to gain the respect of your team, and this is especially salient when you first join. And while it’s true that you will need some more time before leading the team through your first launch (see point one about gaining context before making key decisions), you can gain respect in other ways.  How you choose to do so is discretionary and, in my opinion, highly contingent on understanding how your team currently works. I would recommend having one-on-ones with every member of your team in the first week and make it clear that you are keen to listen to whatever they want to throw your way, inclusive of what is going well on the team and “what keeps them up at night.” Just by listening, you can immediately prove that you are a team-player and that you’re there with the intention of making your team and product successful.

The thrills of joining a new team are numerous, but the experience is not without its challenges. There is no silver bullet for navigating your way through these challenges and these takeaways are far from all-encompassing. Be open-minded and hungry – and you’ll be on the path to success in no time at all.

About Jen Hau 
5p3 - Jhau HeadshotJen is a product person who parachuted to safety from a career as an attorney.  After wearing a number of hats at fast-growing, lean startups, operations to data, she now leads a product team at Hightower, a commercial real estate tech company.  She lives in Brooklyn, New York and is always up for a strong cold brew.

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

So, your boss’s boss walks into your office and changes your roadmap…

Guest Post by: Jessica Waite (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Radhika Nayak]

So, your boss’s boss walks into your office and changes your roadmap…

No, this is not a bad joke.

shutterstock_222658030[1]

As a product manager you prep, plan and execute. You spend months in discovery carefully understanding the customer, the business needs, the software requirements and how to execute it all. Once you discover what the root problem is, you lead a team to making the solution a reality. In my case with my product, I knew the main problem when I started. The problem was an unstable code base that supported (if, and when it worked) all of our internal tooling. The only real solution was to rebuild everything from scratch; requiring phasing out the old platform and creating a new one and managing multiple products and roadmaps. Product 101 was key: understand the stakeholder’s problems,  customer needs versus wants, and making informed, strategic details for feature roll out, and ensuring what you build will scale.

We knew from the start  a better solution to our collapsing software would be a huge undertaking. One of the main things I learned this year was the importance and execution of phasing out products. It’s important to continually question priorities, identify solid wins, and develop a realistic timeline. Anyone who has worked with software knows, you can not just stop development and bug fixes on a current product because you know you are building something new. The platform we were replacing still needed to work until it  all of its core functions were in  the new code base.

Time is the most valued asset but it is in most cases not on your side.

time-management[1]A product manager sets expectations appropriately while maintaining a level of transparency but this can be extraordinarily hard to do. To properly set expectations you have to understand the problem and become an expert in how the product will be used, and how it should work long term. Setting expectations early on depends on having enough information to actually get it right. The tough part is once someone knows you are trying to fix or build a solution they want to know when they can have it. If you don’t know the scope of the issue you can’t solve the problem and you can’t give a realistic answer. While doing phase one of document storage and planning out the execution of the next phase and overseeing the maintenance of the old platform, I was asked if I could rebuild our ticket management system for ads in three months and in doing so move my next planned phase till after I could deliver ticketing. The person on the other end of this question happened to be my boss’ boss.

As humans we have a deep desire to have all the answers especially to someone who is in a higher authoritative position. So you can imagine my stress when this was asked, my new knee jerk reaction was to say yes in order to sound “informed” but in reality that wasn’t planned for discovery for another six to eight months. I had only been at this company for six months and I knew that ticket management was a huge build. My response was, “That sounds like a very aggressive deadline, I can not confirm that until I do some research. I will get back to you after I have had some time to scope this out.”

When you are trying to investigate a problem you need to not only identify your stakeholders but you need to be efficient in getting information. You move quickly to find out what you didn’t know. One of the biggest time sucks for me initially was inefficient meetings. Through talking with my mentor, I found that it is best to keep your meetings with stakeholder small, no more than four or five people in the room. Give them an agenda of what will be covered in your meeting ahead of time. The agenda will help all stay on task and maximize your time together. And if you have good stakeholders, you will be able to identify quick wins that will boost moral as well as the harder to tackle underlying issue. Had I not been allowed this time to properly scope I wouldn’t have had enough user centric information to think this problem through and start phasing ticketing.

Epi-201-M2M[1]

Had I just said yes initially I would have failed in meeting the deadline because I didn’t fully understanding the massive undertaking that was ticketing. I would’ve also failed as a manager because I wouldn’t have known that I needed to hire more people to execute so we could deliver quicker. Discovery alone took three months. Having the old platform as a cautionary tale of being built without scaling in the future in mind, I wanted to solve this and provide a sustainable solution. I initially thought ticketing was made of a few components, a couple forms and one or two workflows. It turns out it was over 35 forms that were riddled with conditional logic, a redundant backend ticketing system, several dashboard views and needed to cater to a myriad of job functions. There was no way that I could have done this just my original team in the initial time asked. I needed to be in the room with with stakeholders, hire another dev, and work with a designer who could establish a pattern library to ensure consistency across the  new platform. Additionally, we weren’t just going to be duplicating what had originally existed, I had to improve it by coming up with a more efficient process and workflow to save the company time and money. Those were all things I needed to identify before I possibly committed to a delivery date. In the end I kept the trust of my upper management because I was transparent, and I didn’t miss a deadline that was unachievable.

I have found in my six months in The Product Mentor Program when you focus on building something that scales and solves the needs of your company by being driven by customer needs, that you have to be all in in order to really solve big problems. This is a hard job but we have a community of brilliant people who have been where you are and are willing to help. The tools you use can definitely help but it is the strategic planning of your phases; learning how to constructively set expectations of both your role and your team; and investing a piece of yourself into the company and your product are what make a good product manager. Even when your roadmap gets changed quickly because of company needs, you will be alright as long as you have established a good cadence of steps to execute

About Jessica Waite 

5p6 - jessicaJessica Waite a Technical Product Manager at Townnsquare Media in New York City. She is currently working on rebuilding all internal tooling for TSM from the ground up. Learning from the prior code base she has implemented new, more efficient workflows, to ensure all around smarter tooling that is focused on the long term scalability of her newly developed product.

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 Priorities with a Stakeholder Roadmap

Guest Post by: Marc San Luis (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Dave Skrobela]

In the education-technology sector, there is one hard-set deadline. That deadline is simple: you must release a working product before back-to-school begins. Period.

When I returned to the Ed-tech sector a year ago, I joined a team with a very aggressive goal. The goal was two years in the making. It was to create a new online education platform and then transition the newest versions of digital product offerings into that platform. All of this must be launched before the 2016 back-to-school season.

I was brought in to head the Data and Reporting platform and eventually started to take on more responsibilities as a product owner of the Teacher platform. One of the biggest challenges I encountered was the overwhelming amount of features my team had to deliver.

201tickets[1]The backlog was growing and the deadline looming. It was at this time that I joined The Product Mentor and was teamed up with my mentor Dave Skrobela. Dave’s experience in the Ed-tech industry was very helpful. We went on to discuss a game plan on tackling my problem: managing and prioritizing the product backlog with these hard-set deadlines.

In order to properly prioritize the backlog, one of the lessons I learned from my mentor is to fully map out the stakeholders. Stakeholders are anyone who has a deep interest in the product. These are the people with direct or indirect influence in the product. It could also include the actual team creating and executing the development to finish the product.

The best way to map out the stakeholders for a product is to build a stakeholder map. A stakeholder map is the best way to document all stakeholders in every project. This map can be used to better inform the prioritization of the product backlog.  

I started my stakeholder map using the template provided by my mentor. However, this stakeholder map template should work for many product owners regardless of the product or the field they are in. The stakeholder map is a matrix that contain every stakeholders that affects the product.

We started the stakeholder map with first listing all the stakeholders we have in mind and grouped them based on whether they are internal vs. external stakeholders.

The best way to figure out whether a stakeholder is internal vs. external to your project is using the following analogy of “The Chicken and the Pig.”

Image result for chicken and pig

I first heard of “The Chicken and the Pig” analogy the very first time I went to an Agile seminar. This analogy does a great job in describing stakeholders in your product and it has to do with gauging stakeholder commitments.

Think of your product as a dish of ham and egg that you ‘cook’. The “Chicken and the Pig” analogy goes something like this: when cooking this breakfast dish of ‘ham and egg’, the chicken will provide the eggs, however the pig will provide the ham of the dish. In this analogy the pig then is the most committed while the chicken is only ‘involved’ in your product.

The chicken is then synonymous with the external stakeholders of your product. They may be the marketing and sales team, the technical supports team, or even your boss’s boss. They care about your product but they are not going to be the one burning the midnight oil to get the product to launch next week.

Internal stakeholders then are the people more directly involved in executing or creating the product. They could be the U/X team or designers and web developers that are in-charge of deliverables that must be made to complete the product.

Once we have listed out all the internal and external stakeholders, these will divide the stakeholders into external vs. internal stakeholders.

image

Figure 1.0

Mapping the stakeholder map in this matrix is very helpful. It shows a clear way of figuring out exactly who or whom we need to listen to, answer to, or work with to prioritize the product backlog. The map is organized into columns. See Figure 1.0.

The first column will of the stakeholder map lists all the stakeholders. The next column we added the ‘Initial Release Impact’. This was an important column for our project to help the team figure out the stakeholders we need to keep in mind to help with the initial release of the product, the people that will help market, support, and troubleshoot the product during launch.

Again, the columns of the stakeholder map can be fully customized based on your needs. However, this exercise is truly vital in figuring out every stakeholder that could impact the project, how the product backlog must be prioritized, or even highlight the people that we must keep in mind as we execute the project.

In our case, my mentor and I focused on fully fleshing out two stakeholder groups. The first is the direct team that will help in the execution of the project. The other is the marketing team that eventually interacts with the customer and also market product features. The next step after we have honed in on these two teams we wanted to focus was to gauge the stakeholder’s level of influence. We decided to create a proper channel for us to focus on these groups via the creation of a ‘Communication Plan’ which is the second step after creating the stakeholder map.

Communication Plan

The communication plan is simply a document we created to figure out the pathways of communication with the stakeholder. This is important in order to fully open this channel of communication with the stakeholders and to set a more consistent plan and timeframe of communication.

business-planning-653x339[1]The communication plan could essentially be a communication mission statement that we created to ensure we facilitate communication with the stakeholder.

In regards to the marketing team for example, I quickly realized that I did not have a way to fully talk to the marketing team directly. The team travels a great deal, and so I resorted to talking to my boss about this concern. My boss was indeed good and mindful about this and he has started looping me into any marketing communication and updates.

We started creating Powerpoint slides to ensure we communicate the upcoming features for the product to the marketing team. In addition, we receive feedback about customer needs as well as ‘marketed features’ that must be released to fulfill customer expectations.

In addition, we are doing our best to extend the sprint demo to the marketing team. Although they are not always available to attend these meetings, they are able to figure out exactly what features are ready to be demoed and often times requests a one-on-one demo. In addition their feedback has been valuable to help my team and I to negotiate, prioritize, and process the product backlog in order to meet the deadline with aligned expectations.

About Marc San Luis

5p9 - Marc_SanLuis-photoMarc is a technologist passionate about education, he currently works in the ed-tech industry as a product manager. He lives in Jersey City and was a former president and current member of the Board of Directors of the SJI Association, a Filipino-American association based in NY/NJ. On his weekends, he loves studying Mandarin as well as reading and writing short stories.

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

Prioritizing Product Innovation

Guest Post by: Ariba Jahan (Mentee, Session 4, The Product Mentor) [Paired with Mentor, James Alexander]

Innovation Labs are popping up everywhere nowadays, from Westwood, ATT to Lowe’s, New York Times, and Zappos. It’s like they all read the “Innovator’s Dilemma” and had a panic attack. They realized that all they were doing was creating “sustaining innovations” whereas they need to start focusing on “disruptions” to capture new markets. Disrupt before someone else disrupts you, as the saying goes?   

Laboratory Glassware

What does a disruption look like? Netflix put video stores out of business by changing how people watch movies. Amazon put book stores out of business by changing how people buy books. Warby Parker changed the entire process of how someone buys prescription glasses and made it affordable. Disruptions can reshape a an entire industry: long distance calls (Skype), record stores (iTunes), local stores (eBay), taxis (uber) and even newspapers (twitter). These companies didn’t become the game changer overnight, it happened over successive iterations and risks that lead to the point where they dominated the customer base.

So companies started building innovation labs to start focusing on creating their own disruptions. Fantastic! This is actually a great thing. But coming to this decision is the easiest part. The execution and implementation are the hardest. So what makes an innovation lab successful? Let’s take a look at some common patterns of their success. Please note, I am not able to disclose the names of the companies to maintain their privacy.

1. Permission and budget to fail.

Innovation is a numbers game. So in order for the team to land on something truly innovative that can be tested and rolled out, they need the room to push out a large volume of ideas that may not work. To support this effort, sufficient budget and resources are needed to turn ideas into prototypes that can be tested. This can help drive an overall culture of “failing forward”. When creative and unique ideas are explored, allow the team to share their learnings from fails and successes openly. The lessons can also be shared publicly as a form of thought leadership and showcase of work.

freelancing-writing[1]

2. Give Autonomy.

The team should have the autonomy to make their own decisions outside of the main business processes in order to continuously ideate, experiment, prototype and test. The entire company’s process  of work doesn’t need to be revamped, but create a way to work outside of the process in order to ideate and prototype large volumes of new ideas or fresh thinking. In order to cultivate this unique energy and process, the team needs to be in a separate space and have access to resources and tools that  would be helpful for them to produce quicker. This allows them to focus on the challenge at hand without having to deal with the account/client management/admin work. The physical space the team works in should be inspiring and help the company use it as a space to break out of normal protocols and experiment. The space can be inviting and open to the entire company to visit so that the innovative ideas permeate through the entire company.

3.Leverage the experts.

Pull in expertise outside of the company that can openly share how they innovate. Company B partnered with a consultant firm for design thinking and company D hired a consultancy to build their entire strategy. When selecting, choose expertise that will be invested in getting to know your company and its language. Outside perspectives help adoption and openness.

4. Make it happen company wide.

In order to get buy-in from employees, there needs to be employee education and engagement with the lab, rather than limiting innovation to something exclusive to the lab space and staff. Everyone should be innovating in their everyday work, whether or not they are working directly in the lab or not. However, to encourage this, employees need education, engagement, and incentives.

5. Always be measuring.

measure-quality[1]It’s important to measure the number of projects and people that have gone through the lab. However, it is also important to evaluate employee experiences in the lab (e.g. “Did you stretch?” “Was it worthwhile?”).  Did you deliver a proof of concept? How do people feel about the lab and their participation? The lab should not have to worry about generating revenue or be too focused on the quantitative success. It should be about testing ideas and learning from those experiences. The products and ideas that result from this approach can generate revenue, if the problem solving service is provided to clients.

In order for innovation to be successful at your company, you have to prioritize creating an innovative culture by allowing the entire company to participate in some way, they should feel like they have the permission to fail and experiment for the greater good of the company. Whether a company decides to have a studio, lab or a strategy, it should have a systematic process that allows the team to execute ideas into testable prototypes fast. The work from the lab can be leveraged to create new business, thought leadership and possibly shift the company into transformative innovations. Innovation won’t happen overnight, matter of fact it may take years and failed attempts before the lab can generate revenue or successful innovations, but when it does the impact can be exponential.

 

 

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

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

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

Make New Product Features Stick

636110236250565651-1646795078_post-it-note-Large[1]

Guest Post by: David Parmelee, Digital Strategy Consultant

As you study the people who use your product or might use it, patterns start to emerge.  A marketer or market researcher may view patterns in terms of demographics and buying activity.  A user researcher or other UX practitioner may group users by patterns in their behavior, both inside and outside your product.

Whether you consider your user base in light of market research or user research, both of these kinds of researchers use the patterns they discover to form personas.  

User personas stand in for users throughout the design of your product.  Each one has at least one goal and at least one pain point.  Using a distinction from About Face, these goals could relate to their lives, the ends they accomplish in working with your product, or their experiences and feelings using your product.  Realistically, they would have one or two life goals, around three end goals, and at least one experience goal.

Why bring this up?

Your users do not all have the same goals or the same pain points.  Therefore, they would not use your product’s new features – or decide to engage with them – based on the same motivations.

Using personas to drive engagement

personas-HEM-Blog-2[1]The main questions to ask when you evaluate a new feature’s relevance to each persona are these:

1. Will this feature help this persona accomplish her goals, not just mine?

2. Will this feature help this persona alleviate her pain points, not just mine?

If a persona says no to both questions, users like her won’t care about this feature, even if you consider it your magnum opus or your product’s big differentiator.

Sad but true.

So don’t bother people like that persona about that new feature.  Instead, tell them about the features that would cause them to say yes to those questions.

You’ll get more engagement that way.

Segmentation and automation

You might think that telling users about new features is all or nothing.

That might be how you’ve implemented it today.

If you have only one email list and your product doesn’t keep track of key differences between the users, you’ll have to implement it that way.

By having separate email lists or segments within your list, you can see where your real customers fit according to your personas.  It also validates how accurate your personas are and lets you know if any are extra or missing.

You can send everyone on your main list a 1-question survey for self-selection to build those lists if you don’t want to do it yourself.  Then email the smaller lists separately with content that is more relevant to them.

Continuous integration in deployment can involve feature flagging.  You might be testing a new feature with a subset of your users, as Facebook frequently does in their experiments.  In that sense, letting users know about a feature that they won’t see will just confuse them.

Users of your product have opted into receiving communications about it if your Terms of Use permit it.  But they shouldn’t receive the same message about your new feature.  

Trivialpursuit-pie_3138286c[1]First, it would be irrelevant to many of them.  Your users are not a monolithic group, where each one of them is just “the user”.  They have different needs and goals, and they use different parts of your product.  

Second, sending everyone the same message means you’ll leave some of the engagement with your announcement on the table – even for the groups of people who would use the new feature.  

Which message is more effective?

  • “Our app is now integrated with [Maps App X]”? 

  • Or “We saw that you look at a lot of [Metro stations] when you use [Our App Name Here].  Now, you can get directions to [these Metro stations] faster in [Our App Name Here] because we’ve added directions from [Maps App X].  Check out how this can [persona goal: save you time exploring our city]!”?

Your product’s mailing list should use marketing automation to onboard and retain users. MailChimp and Drip both provide this.  

Drip works differently because you only have one list, but you can set up workflows and rules to send subscribers specific campaigns within it.  You could easily send users a campaign for a feature if they have visited a related area of your website or app.

Getting a slice of your users to listen

Persona fit is just one way to determine who would benefit most from a new feature.  But it is theoretical, and no method is entirely foolproof.  What other options do you have?

Listen to users’ feature requests

Anyone who requested the new feature you are building has at least thought about the problem that it solves.  If you use a voting system (like Aha) to decide on new features to create, you can notify people that the status of a feature idea they voted for has changed.

Analyze patterns of use

Analytics tools may tell you which features of your product a user has used.  Identify features in your product that help people accomplish similar goals to your new feature.  People who have used these features may be good candidates to engage with the new feature.

You are not limited to only telling people about new features from inside your product.  You can use email to notify inactive users who have used a related feature, provided they have not opted out of emails from you.

Consider which plans are best

According to Intercom, SaaS businesses can use new features as a great chance to upsell more expensive plans.  If there’s a compelling reason why someone with a particular plan should upgrade to the next one up, tell them.  

Use their words, not your own

A trick of great copywriting is listening.  By saying your users’ words back to them, you show that you understand their problem, which led to the new feature you created.  So reiterate the problem that your new feature solves, and articulate a benefit that they will find relevant.

Beware of too much noise

Don’t tell your users about new features too often.  Give them a break between notifications so that they will seem more important.  

Annoying-noise-001[1]This is like visual design: one item that stands by itself and is large looks important.  A bunch of items that are the same size in a cluster or which are cluttered on the page won’t receive a lot of individual attention.

Make extra effort to connect on an individual level

Paul Graham tells startups, “Do things that don’t scale.”  One thing that does not scale is sending personalized messages to your users.  “Personalization” does not just mean an |*FNAME*| mail merge tag.  Make a meaningful connection that shows that you really understand your recipient.  

Tying new features into onboarding

When you tell your users about a new feature, your call to action should link people directly to a tutorial or onboarding tips for using that feature.

But to Stephen P. Anderson and Samuel Hulick, the feature should not be the hero of the story.  Your users should be.

If your feature was designed well, it focuses on a goal of one of your product’s primary or secondary personas.  To convince people that they should use it, tie the feature (and its onboarding) into a goal that they want to achieve.  It could be an end goal related to their task – or even an experience goal or a life goal.

Rather than treating your product’s onboarding like a feature that you only release once, revisit it periodically.  Do new features that you introduce necessitate a fundamental shift in how new users need to get to know your product?  Does your onboarding evolve as you understand your audience and their needs better?

AAEAAQAAAAAAAAw9AAAAJDdmZmFjZjNmLTJkNDItNDliMi05ZDI2LWViYWEwNGQxMTk3NA[1]Reconsidering your onboarding may also give you ideas for refactoring the UI and the broader UX of your product, so that it becomes easier to learn and use.  Instead of building a new feature in isolation, consider what people need to (or might) do before and after using that feature as they use it to accomplish their goals.

Telling users about new features

Release notes and email announcements are two traditional ways to tell users about new features.  The following ways might be more effective.

Explainer videos

Some products use explainer videos to tell their users how to benefit from a new feature.  This is more likely to work for a mobile app for consumers than for a desktop application for enterprise.  Many organizations have IT policies which forbid their employees from watching videos over the internet while at work.

Landing pages

Features that address a significant pain point or a significant objection from new prospects should get their own landing page, following a Pain/Dream/Fix format.  Include screenshots, videos, and sufficient copy to explain the benefits of the feature.  Promote these new features in press releases and social media ads.  

Webinars

Powerful features that go into a lot of depth are good subjects for a 20-30 minute webinar with a Q&A session.

A healthier organizational mindset for new and existing features

UserTesting recommends encouraging a research mindset in your organization or your client’s.  In other words, consider new features to be a bad idea until your organization has researched the need for them and validated that the users will need them.  

In this, let your personas be your guide.

But what if you could measure engagement with a new feature before you even design it?

Fake door idea validation involves creating a landing page to discuss an idea, buying ads on related keywords, and measuring how many users are interested in signing up.  This strategy also works at the feature level.  Create a stub in your product’s UI where a new feature would go, and measure how many people show interest in accessing that feature.

However, sometimes your best efforts at driving engagement in a new feature will not be good enough.  Remove features that your users are not using, while being careful to not damage the user experience with other features.  This saves you maintenance work, while also uncluttering your UI so that more of your users can discover better new features in the future.

Learn more about user research and designing from data
14961790935901_thumb2This article is adapted from content in UX for Development Shops: Declutter Your Interface, Design from Data, & Increase User Adoption & Retention.  You may buy this ebook at https://davidp.io/ebook.

 

About David Parmelee
David-058.jpgDavid Parmelee is the owner of Thrill & Create, a user experience consultancy in Maryland.  Also bringing deep experience in software development for companies ranging from the Fortune 500 to small businesses, he now helps development teams increase user retention in their products.  His client list for UX projects includes large global companies, county governments, and organizations in hospitality and tourism.  His ebook, UX for Development Shops: Declutter Your Interface, Design from Data, & Increase User Adoption & Retention, helps development agencies, teams, and individual developers to achieve better business results by focusing on and involving their target users.  David publishes a video series, More Than an Interface (>UI), and created Teardowns with a Twist, an innovative way to evaluate digital products from multiple personas’ perspectives at once.  Learn more about David at DavidP.io, on LinkedIn, or on Twitter at @DavidParmeleeUX.

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