These Are My Product Management 2020 NEW YEAR’S RESOLUTIONS. What Are Yours?

As in any other aspect of our lives, looking back at the past year and our accomplishments and fulfillments (or sometimes, unfortunately, non-fulfillments) at our job as Product Managers, we all wonder what should our professional New Year’s Resolutions be. 

What I personally try to do is look at how the arena of Product Management is changing and, based on that, come up with the areas I should focus on. I then do my best to clarify and quantify them to the extent that they are comprehensive and measurable for me!

Here are my three 2020 New Year’s Resolutions.

1. Owning My Product: This year I will develop a deep understanding of my product’s value points (how it generates value to my customers) and better understand the relationship with the Product Owner. Here’s how I see it:

2. Being As Data-Driven As I Can: This year I will establish data-driven KPIs that will evaluate my product management performance. I will identify the top areas in which I need to improve and turn them into KPIs:

CET KPIs: Count the number of interaction I have with customers, or how much of my time with customers is CET (Customer Exploration Time), i.e. time I spend exploring customer needs, pains, and values (NOT selling to the customer, NOT trying to manage a customer’s crisis, NOT helping someone else in the organization). I think about CET as my quality time with my customers!

Competitor KPIs: Define my top five competitors (direct and indirect) and identify how they rank against my product on the top five value points. Ask myself: how well do I know this 25-point map?

Monetization KPIs: Measure my ability to build a business case. Rate myself on a scale of 1 to 5 on how well I know it.

Product Objective Board KPIs: Build my Product Objective Board – key parameters from my business case which I examine on a weekly or a monthly basis.


3. Understanding That I Too Am A Product: This year I will think of MYSELF as a product. How much do I invest in making myself a better Product Manager? Can I build KPIs that are focused on making ME a better Product Manager?

What are your 2020 New Year’s Resolutions?

The Product Owner does not own the product

Product Manager and Product Owner are two separate roles; however, both roles are under the responsibility of the product manager.

In his well-known article, Good Product Manager/Bad Product Manager, Ben Horowitz wrote: “Good product managers take full responsibility and measure themselves in terms of the success of the product”. That includes, of course, making sure that the product owner role is performed as required – the detailed user stories reflect the product manager feature definitions, the prioritization is aligned with the product goals, etc.

While the product owner’s duties can be performed by the product manager, it is not mandatory. When one person performs both roles, it may result in focusing on urgent matters on the account of delving into long-term, strategic activities. A product manager working closely with a product owner (rather than filling this role on their own) can focus on the big picture, without the risk of neglecting the detailed work with R&D – this work is  handled by the product owner, supervised by the product manager.

One challenge that arises when the product owner is NOT the product manager is that one of the product owner roles is to represent the voice of the customer to the technical team. If product owners get market inputs only from the product manager and do not have direct access to the market, their ability to represent the customer’s view to the R&D team is limited. This should be solved by involving product owners in customer meetings and other opportunities for direct access to the market. In such case it is important that the product owner’s understanding of the customers is in sync with that of the product manager, so that the message from the market to the organization is coherent.

When working this way, the product team’s interfaces with the rest of the organization are clear – the product owner is the principal point of contact for the R&D team, and the product manager is the principal point of contact for the marketing team, sales team, etc. There should be a well-defined working procedure between the product manager and the product owner to ensure that the product owner’s translation of requirements to user stories aligns with the product manager’s understanding of the requirements, and that they share the same, up-do-date understanding of the market.

A product owner can be of great help to the product manager, as long as the product manager maintains an end-to-end responsibility over the product, including the work done by the product owner. If a product manager thinks her responsibility ends when the product definition is delivered to the product owner for execution, she does not understand her role as a product manager and cripples her ability to build a successful product. Taking control over the two roles, even if one is performed by a different person, is a key element in the success of the product.

Product Manager – what is your data Analytics Strategy?

Companies that operate in the digital market today have access to comprehensive data about their products, making data analytics a key to business success. As a result, the market for data analytics solutions became very competitive with multiple vendors that offer tools with more and more features and great user experience.

It seems simple. Implement a data analytics tool, visualize your data and make data-driven decisions. Does it work in practice? Do most companies manage to convert data to actions?

Data analytics platforms generate beautiful daily reports containing a lot of substantial information. Is anything done with these reports after the first several weeks? Usually, based on my experience, the answer is no. As Paul Sartori of Station 10, says, “If it (the report) has no action, it’s not worth spending time on”.

The Common Practice

Product managers and analysts usually focus on defining an event table that contains all possible events (better safe than sorry – you do not want to discover that important data was not recorded). Then, they build a dashboard that displays the main parameters (new users, retention, conversion rates, etc.). That should work, right?

Not exactly. The result of this common practice is that we have too much information, which limits our ability to focus on the important data. In many cases, you find out that it is very difficult (if not impossible) to obtain the piece of information you really need. You are working hard to drill down and get the right answers, instead of finding the right questions.

In the case your analytics reports indicate that your product is not doing well, the obvoius next step is to investigate why it happens and what needs to be done. As Paul Sartori adds: “Why not do that in the first place instead of wasting time on pretty but pointless dashboards?”

The problem with the common practice is that it is a bottom-up approach. We gather all the details and end up with a huge pile of hay of data, trying to find our needles. Instead, we need to use a top-down approach, to anticipate where the needles will fall. Focusing on the important, actionable data.

'Right-side-up' Analytics Methodology

To be data-driven means to use data to the right decisions that serve your strategy. Therefore, we should select the most relevant metrics that will enable us to get answers to the critical questions that will enable us to execute our strategy.

The strategic steps for right-side-up data analytics implementation are:

●       Define your goals

●       Select the metric / KPIs that really matter

●       Ask strategic questions to explain cause

For each goal, we should define what can affect it and the potential causes. The deeper we dig before defining the metrics the better, since once we start defining metrics we will tend to forget the questions and focus on more metrics.

The next steps are tactical:

●       Choose the investigation methods to answer the questions

●       Create an event table / tracking plan

Choosing an effective investigation method is supercritical. Data analysis can be very time-consuming if a more complicated method is used. I made this mistake too many times to learn that over exploring usually causes more harm than good. Optimize your investigation methods – look for the shortest path to the answer, thus reduce the chance for data overload and errors.

The last step is where the common practice starts – defining the events table. At this point, we have all the logic – we just need to define the required event and make sure we do not forget anything. It is important to:

  • Use the minimal number of events possible
  • Truly utilize the power of event properties to indicate context and causation
  • Be very specific and detailed with explaining each event’s triggers and properties syntax.

About the author: 
Yoav Yechiam is the Chief Analytics and Product Strategy consultant at Y-Perspective. Yoav teaches Analytics courses and workshops, lectures on Product Strategy and Analytics and have published a few articles on that subjects.

Learn more about Data Analytics

StarVision has partnered with Yoav Yechiam to deliver a laser-focused 12-hours Analytics Mastery workshop in which you will learn what, how and when to measure and get acquainted with various Data Analytics platforms.

Tips for effective PM Tool implementation – Part 2

In our previous post we described what should be done before starting implementation of a Product Management tool. This post provides tips for the implementation process.

Tip #5 – Customize the tool for your organization

Product Management Tools come with a generic data model and workflows. To provide the highest value for your organization, these generic processes must be customized to the product processes that work for your organization. While you may decide to adopt built-in processes that can help you, the tool should support product processes that work well for your organization.

Product Management tools are usually highly customizable. Analyze the product processes you use today, decide which processes you want to keep and configure the tool accordingly. If there are product processes that should be improved, use the tool capabilities to build better processes.

Tip #6 – Hold a practical workshop

Once you defined how to work with the tool in your organization, we recommend holding a workshop with the Product Managers to kickoff working with the tool.

In this workshop, the Product Managers start building their products in the tool so that it will be easier for them to work with it by themselves later. Walk them through the tool’s screens and ensure that they start inserting their product’ data. Allocate minimal time for explanations and most of the time for working with the tool.

Tip #7 – Provide guidance and support

After the workshop, when Product Managers start using the tool, they are likely to encounter questions regarding the workflow and methodology. Make sure they get the support they need as long as they need it.

This means that a person familiar with the Aha! implementation in the organization should be available for questions. In addition, we recommend holding periodic 1-on-1 sessions with each Product Manager to help them progress faster.

Tip #8 – Involve related teams

The introduction of the Product Management tool will impact R&D and other teams that work with the Product team. Involve relevant people from other teams in the process, so that they understand the implication on their work and the benefits for them. Show them the outputs from the that are relevant to them tool (e.g. requirements to R&D), get their feedback and address their concerns.

Tip #9 (for large companies with several products) – Start with 1-2 products and expand

When you start working with a new tool, you are likely to make mistakes in your initial definitions, especially when multiple people start working with a new tool at the same time. This can result in wasting time logging information in wrong places and having to repeat work, creating a feeling that you work for the tool instead of having a tool that works for you.

Therefore, we recommend starting with 1-2 products, validate that the tool is defined well for your organization and only afterwards expand to additional products. This will also enable you to show the rest of the Product team how the tool helps the first Product Manager, thus motivating the rest of the team to start using the tool as well.

StarVision helps companies implementing Product Management tools, ensuring smooth transition, short implementation time and effective implementation.

Tips for effective PM Tool implementation

So, you realized that your current SW tools do not cover important aspects of your work, such as roadmap and product strategy. You also realized that the presentations that sometimes are used to capture those artifacts are not easy to manage. Therefore, you decided to introduce a tool built for Product Managers (if you have not decided yet, see “Should you use a Product Management tool?”). This requires a change in the way your Product Management team works and impacts other teams as well. How do you make this transition smooth and start enjoying the tool’s benefits?

Before you start

Tip #1 – Lead the change

It is not easy for most people to change the way they work.  People make their actions into habits and soon they get comfortable with what they do.  Transitioning into using Product Management tools we need to realize that we are about to encounter resistance to change.  This resistance takes many shapes and forms.   Some Product Managers will just avoid the issue all together, “so what if the roadmap is in Power Point and nobody knows what is the most up to date version…”

To make the transition happen, someone has to lead the change.  If it is not the Head of Product Management, assign one of the Product Managers to lead the change.

Tip #2 – Obtain Management support

This is generally true for any significant transition that you want to lead. In the case of introduction of a Product Management tool, highlight the benefits for Management:

  • Better visibility – Management can always have a look at the most up-to-date artifacts, such as your roadmap, personas and competitive analysis.
  • Product execution alignment with strategy – using best product practices and making it easier to understand the status of each product – resulting in a more effective and focused Product team.

This issue can be key to your success with the Product Tool implementation project, so it is extremely important that you identify and conduct one on one meetings with key stakeholders to ensure their support.

Tip #3 – select the right Product Management tool for your organization

Over the last few years, several Product Management tools have been evolving – Aha!, ProdPad, Product Plan, ProductBoard, Craft and others. Some of these tools provide full product cycle coverage while others are focused on certain aspects such as roadmap or the business side. Some tools have more capabilities and are more flexible while others may be simpler and easier to use. The decision should be based on the goals you want to achieve – for example, strategy definition, better prioritization, transparency, improved communication with other teams.

Tip #4 – Onboard your Product Management team

The Product team is key to the success of the tool implementation. If the tool does not provide value to them, they will not use it. The challenge is that to enjoy the benefits, they need to invest some initial work.

Show them how the tool will help them be more effective by enabling them to focus on adding value to their product and providing an easy, structured process from strategy to execution. Start with time consuming activities (e.g. periodic management reports) that can be done much faster and easier using a Product Management tool to show value quickly.

The next step is to start the implementation. See our next post for tips regarding how to manage the implementation process.

StarVision helps companies implementing Product Management tools, ensuring smooth transition, short implementation time and effective implementation.

Stop the Press: The Product Owner is NOT the Product Manager

The Product Manager has end-to-end responsibility for the Product success. According to StarVision Product Methodology (SVPM), the Product Manager role includes the following dimensions – Product Strategy, Product Definition (from high level roadmap to requirement definitions), Product Achievement (working with technical teams to implement the product definition) and Product Marketing (in some cases Product Marketing is handled by a separate role, the Product Marketing Manager).

Agile SCRUM methodology introduced a new role, Product Owner, which overlaps the Product Manager role, but does not cover all Product Manager’ responsibilities. The Product Owner focus is internal – providing detailed requirements to the implementation team and work closely with them throughout the development process. The Product Owner represents the product in the implementation team, and therefore should be aware of the market and relevant stakeholders needs.

Two Separate Product Roles

Product Managers should focus on the market, and bring the outside world into the organization. They should be involved in the implementation process to ensure the developed product meets the market needs.

In SCRUM, the Product Owner is required to be available to the implementation team almost all the time – make sure detailed requirements are ready on time, reply to queries, attend all rituals and more. Under this pressure, it is very difficult to allocate enough time to be a market expert.

Furthermore, Product Owners are extremely busy with current sprint tasks, and at the same time preparing detailed requirements for the next sprint. They always lack time for longer term and more strategic activities involving various stakeholders like customers, partners, sales, marketing, delivery and more.

Therefore, my recommendation is to separate these two roles to two different people – a Product Manager, who is market-focused and responsible for longer-term activities, and a Product Owner, who is internal-focused and responsible for short-term activities.

This does not mean that Product Managers should not be involved at all in the implementation and that Product Owners should not be in touch with the market. On the contrary – Product Managers should ensure that the implementation serves the product long-term goals and Product Owners should have direct access to the market (e.g. meet customers and get their feedback) in order to represent the product point of view towards the implementation team – but the focus of each role should be clear.

Wait, what if we are too small for two roles?

In smaller companies, there is no budget for 2 product roles and the solution is one person responsible for both Product Manager and Product Owner roles. In such case, management should verify that long-term activities are not neglected (for example, using recurrent strategic meetings in which long term activities are discussed). This should be a treated as a temporary solution, and as soon as possible, this unified product position should be split to two (one Product Manager and one Product Owner).

5 Tips for SAAS Product Managers

In SaaS Products, the software provider controls the operation. SaaS Product Managers have more freedom to schedule new versions and updates, and have access to their product’ usage data. So, how can you use it for the benefit of your product?

Tip 1: Continuous Deployment requires Continuous Product Management

New versions and updates in a SaaS Product do not require marketing the new version to customers and deploying the new version for each customer. Therefore, SAAS Products updates can be frequent and in some cases Continuous Deployment is used (Suzie Prince provides an excellent overview of Continuous Deployment in mind the PRODUCT blog).

SaaS Product Managers should apply continuous product management processes to utilize the advantages of frequent deployment. This means continuous product definition process – from continuous review of the product goals, roadmap and priorities to frequent communication of detailed requirements to the technical team, as well as continuous product marketing process (frequent micro launches instead of major launch of a new version).

Tip 2: Get new ideas in front of your customers faster

Avoid wasting too much time on internal iterations. Do not hesitate to introduce changes – as a SaaS Product Manager you can introduce small changes and iterate using real market feedback – a much more efficient process than work internally and make assumptions regarding market feedback. You can use AB testing to check new ideas on a small number of users and launch to all users based on market response.

Tip 3: Continuous improvement

Define relevant metrics that will enable you to analyze your product performance.  Use the data to check what works and what does not (both success and retention). Analyze the data, understand what the market is telling you, and use the insights to improve the product.

Tip 4: Do not lose contact with customers

Having usage data available, it is tempting to focus on these metrics and assume that they provide all the information you need. They do not. You have to engage with customers in order to understand their day-in-a-life, understand the value beyond the metrics. Allocate time to speak with customers and bring the insights to the product in addition to the metrics.

Tip 5: Do not lose the big picture

When dealing with many small changes, there is a risk of losing focus. As a Product Manager your job is to add significant value to the product and make it better for the customers. Keep the big picture in mind and make sure the result of the many small updates add up to greater customer value, improved user experience and more satisfied users.

The Final Showdown: The Product Manager and the Product Owner

It happens every time. Organization goes Agile. Smart move. Development organization makes the adjustments. Many adjustments. Next you see sticky notes hanging on office walls and in conference rooms. The art of the hi-tech generation.

Agile has many benefits for some tech organizations.

But one of the dilemmas that Agile raises is around where do requirements come from and how Product Management is incorporated or interfaced into the Agile organization.

To B2B or B2C Product Manager?

Both B2B (Business-to-Business) product manager and B2C (Business-to-Consumers) product manager are responsible for managing their products throughout its lifecycle.  However, their day-to-day work can be very different. So whose job is better?

Note: while there are B2B products that are sold in large volumes, and are similar in some aspects to B2C products, I refer here to B2B products that are more complex and are sold to a smaller number of very big customers at a high price.  

Data, BIG Data

The number of customers of a B2B product is usually in dozens, hundreds or in the better case thousands, while a B2C product can have millions or even billions of customers. A B2B Product Manager who wants to get market feedback in advance can speak with friendly customers (and hope their opinions represent the market) or conduct a survey (hoping that the number of respondents is sufficient and that their answers represent reality).

A B2C Product Manager has a more direct exposure to the market. For example, a B2C Product Manager that manages a cloud-based service can use multiple versions and conduct AB testing to check which UX is more efficient, or to set different prices in order to see which price works better.


The strategic customer bear hug

In B2C, the average deal size is small. You need many deals to generate significant revenue. In B2B, one customer (or a few) can generate a significant percentage of your revenue.

The upside for a B2B Product Manager is that a few good deals can make your product profitable. However, having a small number of customers make them strategic for your product success. As a result, the B2B Product Manager is under pressure to develop custom features for the important customers, which may distract the product from its course and may make it a custom solution that meets the needs of specific customers, but is not relevant for the rest of the market.

Who buys your product?

In B2B, the product users are not usually the buyer. Furthermore, as the purchase decision has to be approved by multiple people in the buying organization, the B2B Product Manager should take into consideration (besides the user) the buyer and other influencers who are critical to the sales process.

Customer relationships

B2B Product Managers maintains close relationship with customers. It can start from presales meetings and continue in ongoing face-to-face meetings and calls throughout the product life cycle, before and after launch.

B2C Product Managers usually do not know their customer. They can hold focus groups, run surveys and interviews to learn their customers’ point of view, but they do not, usually, have ongoing relationship with them.

Your daily activities

Both B2B Product Managers and B2C Product Managers write product definitions, prioritize features and work with other teams (technical, sales, marketing) to bring the product to the market.

If you are a B2C Product Manager, you usually start your day checking the latest analytics to see what works well and what should be improved and you continuously plan AB tests to optimize the user experience. If you are a B2B Product Manager, you invest more time in customers meeting/calls and work closely with the sales team to obtain market info.

So, which job is better?

At the end of the day, it is a personal preference. If you prefer longer cycles, like to develop relationships with your customers and work closely with the sales team, you may enjoy more managing a B2B product. If you like analyzing statistical data and are focused on user experience, you may enjoy more managing a B2C product.

As a Product Manager, you do not have to select either B2B or B2C. In order to be able to manage both B2B and B2C products, consider where you are on the B2B-B2C spectrum, and work on the skills required for the area you are less experienced in.

6 challenges Telecom Product Managers deal with

Companies that sell to Telecom companies and specifically to Mobile Operators, face a market that consists of several hundreds of potential customers (out of which a few dozens are tier-1 operators) and have distinctive characteristics. Product Managers that work in such companies have to deal with some challenges typical to the Telecom market.

Pressure to develop features per customer

Mobile Operators are big organizations that have superior negotiation power over their vendors.  In most cases, the mobile operator will publish a bid with specific requirements that your product need to comply with in order to win the deal. Since deal sizes are usually significant for your company, as a product manager you are under pressure to develop features required by a specific potential customer.

Mobile operators are different from each other and often have different product requirements. Therefore, if you are not careful, you can find yourself with multiple silo projects instead of a product. To avoid this situation, you need to make sure your product is highly configurable, and have customization layers that enable maintaining common modules that are identical for all customers and at the same time support specific customer requirements.

Identifying common requirements

The number of potential customers is several hundred at most (the global number of mobile operators), so market data is more difficult to obtain. You need to obtain data from customer meetings, surveys and RFx documents.

In many cases, your information is based on interactions with a relatively small number of customers and potential customers. Do not assume that if, in 3 out of 5 meetings, customers requested a specific feature, it means that most operators will want it as well. Try to obtain information from many mobile operators – through more customer meetings, RFx documents (list of requirements shared by mobile operators as part of a bid) and surveys to get a picture that better represents the market.

Satisfying multiple personas

Mobile Operators are complex organizations where multiple departments are involved in the purchasing decision. Engineering, Marketing, Finance, Operations and Customer Support may all be involved. For Product Managers, this means that they need to consider multiple personas that represent all key decision makers and make sure the product provides value to each of them and does not have negative value to minimize objection (e.g. Operations object a product that is complicated to operate).

In some cases, Mobile Operators use the product to provide a service to their customers. This is a case of Business-to-Business-to-Consumers (B2B2C), in which in addition to the Mobile Operator personas, the product should provide value to a consumer persona (end-user).

Long sales cycle

Standard sales cycle in Telecom includes multiple bid phases and takes between 6 months to over a year. Upgrades of products that are installed in the operator network are usually not simple and do not happen often. This cycle affects the time-to-market and slows the introduction of new features to the market. Product managers have to take it into consideration in their roadmap and version release planning.

Budget shrinkage

This means that mobile operators invest less in value added services (VAS) and are more focused on reducing their expenses. It is more difficult to convince mobile operators to purchase, so your product must have a clear business case that shows your product can generate significant revenues or reduce cost. Mobile Operators will want to test it in their production environment before they are convinced, so it should be possible to conduct Proof-of-Concepts (PoC) with your product at minimal cost for both your company and the mobile operators.

The impact of NFV

There are predictions (e.g. by Northstream) for a breakthrough and strong growth in NFV activities in 2017. It seems that the hype is phase over and it is time for NFV to really take off. If the prediction is correct, Product Managers should analyze how it affects their product. Product Managers should ask whether it is an opportunity or a threat, whether their product should be adapted for NFV and take the required measures to benefit from this change.