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.

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.

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

Jessica 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 MentorThe 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

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.

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.”

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.

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.

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

Marc 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 MentorThe 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

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?

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.

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.

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 MentorThe 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

In a recent live stream from one of our mentors of The Product Mentor, James Alexander, lead a conversation around “Product Innovation @ Google”. We are always looking for more product mentors from all around the world. Signup to be a Mentor Today!

View the live stream…

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from 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…

In a recent live stream from one of our mentors of The Product Mentor, Jenn Bornstein, lead a conversation around “Building Product Team Morale”. We are always looking for more product mentors from all around the world. Signup to be a Mentor Today!

View the live stream…

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from 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…

Why do I need a framework?

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.

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:

The requester’s role

The desirable outcome once request is delivered

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”

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.

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 1Tradeshow(1/15/2017)

Milestone 2Client Demo(12/25/2017)

Rocket BoosterSpace Suit

Ions EnginePilot 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:

It can be used when communicating across any layer of management or external stakeholders

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.

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.

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

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 MentorThe 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

Featured Product: WayBetterexploring the product, its challenges and successes, from alpha teams to expanded support

Avoiding Feature Creepfrom managing expectations to elevating voices … and much more

The Product Groupmeet-ups are an opportunity for Product People (managers, strategists, marketers, etc.) to come together to meet, interact, and network in a roundtable setting. It’s awesome to meet fellow Product People in a laid-back, conversational gathering.

If you are a Product Person and are interested in having your product featured or participating as a featured guest expert at an upcoming meetup of The Product Group, contact me(or email at jhorn (a-t.) tpgblog DoT com).

In a recent live stream from one of our mentors of The Product Mentor, Addi Regev, lead a conversation around “Agile in the Real World”. We are always looking for more product mentors from all around the world. Signup to be a Mentor Today!

View the live stream…

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from 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…

Like this:

In a recent live stream from one of our mentors of The Product Mentor, Vasu Vadlamudi, lead a conversation around “Balancing Data and Design in Product Management”. We are always looking for more product mentors from all around the world. Signup to be a Mentor Today!

View the live stream…

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from 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…

In a recent live stream from one of our mentors of The Product Mentor, Paul Hurwitz, lead a conversation around “Maximizing LinkedIn for Product Managers”. We are always looking for more product mentors from all around the world. Signup to be a Mentor Today!

View the live stream…

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from 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…