5 ingredients to building great product

Building great product requires a mindset with multi-disciplinary skills. Every Product Manager would learn those skills only through hard way of building products, validating those products with customers and reinforcing the feedback back into building better products.

Based on my experience, I have listed 5 key essential ingredients to building great products.

  1. Audacious problem– Pick an audacious problem to address that no one has addressed it earlier or neither addressed in a way that you are addressing it. Doing so, the product will exceed every expectation to the astonishment of your target customers. All along ensure that customer really care for the problem to be addressed and they definitely pay a premium for addressing it. For doing so, you need to have extensive knowledge about customers and their needs.
  2. Think bold, think future– While picking a problem, think how it manifests in future. Do not just provide a solution for today’s problem. Even though it is critical to address today’s needs, your focus should be on extending the solution to address tomorrow’s needs. While addressing the problem or need, do not constraint yourself with existing technologies or existing benchmarks (What Elon Musk did to electric cars). Probably, your idea or solution to address the need or problem should pave for new technology evolution or change in customer behaviors. When Steve Jobs thought about the problem of stacking 1,000 songs in a device, he would not be constrained by whether any existing technology can store so many songs in a small form factor. Instead, his idea would have driven the evolution of such technology.
  3. Simplicity– This is one principle that is essential for every product. No matter how complex problem you are addressing, there should be simplicity written all over it on how customer will use the product to address their problem or needs
  4. Do one thing right – Be focused on doing just one thing. Do not be everything to everyone. Even if your product has to do multiple things, just focus on delivering awesomeness on specific elements of the product that will drive customers preference towards the products, instead of doing everything right.
  5. Impeccable execution – Nothing beats impeccable execution of the new product. Even a mediocre idea with perfect execution will win over an awesome idea with poor execution. As Ben Horowitz rightly said, focus on the little things and big things will take care of themselves. The statement is true more so during product development, Product Manager should start focussing on all little things even as simple as color and package of the new product.

Are the above five, the exhaustive list? Definitely not, there might be other things as well, but this is what I have learned from my experiences. It is not essential that all great products adhere to the above. For instance, some great products can address a simple problem, but the experiences that they deliver to customers will be a real differentiation.

Beyond those 5 attributes, the most primary aspect is to Start defining the WHY – Strong product vision that outlines the purpose and belief behind the new product

Finally, Product Manager should believe in the product, should believe in her abilities and in the abilities of her team to build an awesome product.

I captured some of those details in my eBook (free copy): Building New Product

Disclaimer: Even though I have built products, I fell short of building great products. I definitely learned how to build awesome product through the hard way of building and failing:-(.

 

Why every Product Manager should know Machine Learning

Machine Learning (ML) is becoming ubiquitous and every single product out there is attempting to use some flavor of Machine Learning to better address customer problems and delight them. Even though ML is still evolving, it is no more a fad and it is not restricted to those familiar use-cases of image recognition, page ranking, spam detection, autonomous cars etc. Appropriate use of ML algorithms is essential to differentiate every product and deliver better value proposition to its customers.

Machine learning is evolving faster than any other technology and it has the potential to break new grounds creating more opportunities through providing solutions to problems that were evading us for a longer time. Even products that are not entirely ML dependent, where it already addresses a certain problem, harnessing ML can help the product better address the same problem. ML is soon becoming the de facto technology for every product and its Product Manager, ML offers only two choices (1) Embrace ML effectively or (2) Fad into oblivion. Ideally speaking, there is only one option to pick.

In this entire conundrum of how to embrace ML, can ML offer an effective solution and what are the other alternatives, how ML is better than those alternatives, how to validate the efficacy of ML, and what is the real value delivered to customers? What do you think will be the role of PMs? Please be aware that the context of this blog is to products that are not entirely ML dependent unlike autonomous cars, speech recognition etc.

Great PMs should be tremendously good at discovering, identifying and later defining the problem – What is the problem that the product has to address. Great PMs spend time identifying a problem that is worth addressing. Focus on technology and solution is always secondary. Technology always evolves and so does solution. Identifying the right problem provides the right start to identifying the right technology to delivering the right solution. PMs should focus on identifying the problem and it is entirely the responsibility of engineering to identify right flavors of ML based on the problem statement provided by PM.

Then… Why am I bragging about PMs being aware of Machine Learning? I foresee three reasons for it.

 

Speak the language of engineering

Even though, PMs should focus more on the problem and less on the solution and PMs need not play a role in drafting HOW to address the problem using ML, PMs should definitely have the technology acumen to understand the HOW.  Understanding of HOW will position PMs to unbiasedly evaluate how exactly ML is better at addressing the customer problem, does it really add significant value. Incorporating ML does not automatically bring results. There is no magic behind ML. ML has to be harnessed in a right way with a right set of data and models to contribute the right value. Rightly so, It is the not the destination that is always important, the journey is also equally important to ensure that PMs took a notice of the efforts by the engineering team and not just the outcome. I always believe in rewarding efforts and not just outcomes. During the journey, PM should speak the language of engineering to comprehend their efforts and to assist them as well. Let me imagine a fictional conversation between my engineer and me after I asked for his assistance to help me predict product revenue based on earlier collected data.

Engineer: Hey Murali, I have used multiple models for classification problem. However, the bias is too high with all those models and we have a problem of underfitting. Guess we need more features.

Me: What are features?

Engineer: Any additional information that can augment existing customers data.

Me: Oh, I have customers age and country.

Engineer: Is there a strong correlation between country and the revenue generated

Me: Hmm … Correlation? I doubt

Engineer: No, the data is not useful we need something else. Unless you provide additional data, I cannot build a good prediction model

Me: Completely lost in the jargons, not sure what data to collect. Notwithstanding, I do not know a dime about ML, I will start doubting the capabilities of my engineer. I gave data of 1000’s of customers. Yet he is asking for more data, what the heck?

PMs interface with many entities (Engineer, C-Level Execs, Sales, Marketing, and Account Teams etc.) and speaking their respective languages gain mutual respect and trust. When I insist PMs should learn ML, I am not focussing on the ability to build a new model but to understand existing models and at least to the extent of mapping the problem on hand to one of the right flavors – Prediction, classification, ranking, clustering, or anomaly detection etc. PMs should understand the overall landscape of ML to differentiate reality from fad and for absolute clarity on what is possible to solve using ML.

 

What lies beneath the surface?

Customers (mostly B2B) are not merely interested in what happens above the surface, they are keen to understand what happens beneath the surface as well. It is essential for Product Managers to explain how the product works in addition to articulating what the product could do for them. Without understanding the specific flavor of ML used in the product and how it is improving the overall efficiency of the solution, it would be tough for Product Manager to succinctly articulate the details.

There is a $ at stake and B2B products are evaluated rationally than emotionally, so the person implementing the product will be curious to know what data is used to validate models and what is the accuracy rate of the outcome. Customer will be interested in knowing the precision score, recall score, and F1 score. In simple terms, customers might be interested to know the rate of false positives and false negatives to consolidate his confidence on the outcome delivered by the product.

 

ML will soon be as fundamental as Excel to PMs

After I scratched the surface of learning ML through online courses at Coursera and with hands-on of Python courses. I primarily understood two things that ML can soon become de-facto technology for data visualization and analysis alike Excel.

  1. Presenting the data is a fundamental skill that every PM should possess. Companies are sitting on top of goldmine of data related to products gathered internally and externally. With increase in collection of data, there should be efficient ways to process and visualize data to get newer insights through adapting newer scalable techniques. The technologies used for presenting the data should evolve and PMs can no more restrict their expertise to basic some graphs in XLS.

Matplotlib, Seaborn and various other libraries are having tons of pre-built plots to visualize data in a meaningful way. Using those libraries are not rocket science. Anyone with basic knowledge of programming should be able to use them. Considering that majority of PMs are either developers or designers, using those visualization libraries should be a piece of cake. What matters is that the options those libraries provide to visualize data is tremendous. PMs do have huge chunks of marketing, sales data on their hand. It might not be always feasible taking assistance from engineering to choose right plots for visualizing the data. Visualizing data can provide more insights than plain numbers on a sheet of paper. There are options for bar plots, scatter plots, correlation through heat maps, country/world map etc.

PS: Some of those libraries are already available with excel, but I feel Python provides more flexibility. Using Python reminisces those lots days of programming. Guess, once a developer always a developer :-).

 

  1. It is not just visualization, analysis of data is also important. At a very fundamental level, every Product Manager should forecast revenues or assess the probability of a deal to succeed or not, cluster customers into segments based on certain common demographic elements. Again, I am speaking mostly from the context of B2B segment. For data analysis, PMs can understand the nature of the problem – prediction, classification or clustering and pick one of the already available algorithms to analyze the data. Ability to interpret errors such as mean squared error, f1 error etc. on both training set and validation set can help Product Manager identify alternate solutions to address bias/variance tradeoffs. The Internet has tons of pre-determined solutions for addressing bias/variance tradeoffs for various combinations of bias/variance problems. ML is definitely a valuable tool for analyzing data and constructing meaningful interpretations of marketing data to define pricing, design market campaigns, define strategies to acquire and retain customers etc.

 

How did I got started

Ever since I started learning ML, I love every bit of it. Probably, it was because of my passion for mathematics and I have a background in statistics. If you detest numbers, then I bet ML will definitely be boring for you.

My journey started with a course in Coursera by Andrew NG. It provided me a basic understanding of Machine Learning fundamentals.

  • What is supervised and unsupervised learning?
  • What are various models under each of those categories? How to identify the right model depending on the use-case?
  • How to measure and interpret error for various algorithms?
  • When to use regularization?
  • What is bias and variance? What are techniques for bias/variance tradeoffs?
  • When to add more features to existing data and when to augment more data to existing data?

Awareness of above details is sufficient to speak the language of ML with engineering, to understand, appreciate and complement their efforts,  and comprehend what is truly possible with ML.

Andrew NG course also requires some amount of programming. It is not too difficult as they do too much of handholding. If you have been a programmer earlier, try to avoid the normal use of loops and instead use vectors to solve problems. Vector methods are faster and pretty much the entire algorithm is programmed in almost one single line. Utmost 90% of the problems, I solved using vectors. Before you get started, gain some basic understanding of vector operations. For me, it took some time to realize that [A] * [B] is not equivalent to [B] * [A] and also to realize that vector multiplication of 2 elements are possible only if the number of columns of the 1st vector is equivalent to the number of rows of the 2nd vector. Ideally, brush your fundamentals in mathematics, if you are more interested to know how algorithms are derived for various models then you should familiarize in algebra and calculus.

After Andrew NG course, I explored for few courses in Udemy for hands-on experience exploring ML algorithms and I picked the following course: Python for Data Science and Machine Learning Bootcamp (it is cheaper :-)). I completed 50% of the course and the focus is exclusively on using existing Python libraries for solving ML problems. However, the course does not provide any theoretical foundation on the background of various ML algorithms. I am loving every bit of my journey so far. I hope that I will sooner start solving some basic problems in Kaggle. However, for PMs, I would suggest to start and end with Andrew NG course, unless you intend to dive deeper.

MIT also offers a course on Machine Learning. If you are looking for a dataset, Kaggle offers many datasets to play around with ML algorithms. Another good resource is MNIST. In addition, IBM Watson also offers certain tools for validating problems related to data science. However, I am yet to explore it.

Please share your thoughts and opinions on learning ML. I wish good luck in your journey of learning ML.

The WHY behind the Product, have you defined it?

What is ‘THE WHY’ behind the product? Why it is essential for every Product Manager to identify it?

Why - PurposeAll of us intend to build and evolve better products. However, we lose the plot blindly chasing competition and trying to appeal every customer that comes our way. Eventually, the product loses its purpose without any direction. How many of us can unambiguously articulate the THE WHY behind the product that defines its purpose in a single tweet?

I am sharing my thoughts on why it is essential to define THE WHY behind the product even while conceptualizing it and how THE WHY can transform the way we build our products and how it will convert our relationship with our customers from a transactional into a relational engagement.

THE WHY behind the product can unambiguously articulate why the product is built both from the perspective of Organization and customers. Further, the Organization beliefs lay the foundation for the purpose, together they define how the product is built and evolved, and they provide a framework for decision-making governing the product. Whatever a Product Manager does in relation to the product – strategy, vision, roadmapping, marketing, pricing etc. is eventually tied to one single element called ‘THE Purpose’.

What does your Organization believe in – Is the product built upon that foundation of belief? New product built without any belief sans purpose. What the new product could do and how it could do does not define the purpose. Those are transactional items purpose is much bigger. Purpose underlined by a strong belief puts every stakeholder involved with building the new product in a state of self-actualization where they are inspired and motivated to do what they do. Purpose can also define the marketing message that will make customers believe in the product believe in what it does. The difference between good and great product lay in its ability to define why.

The difference between good and great product lay in its ability to define why

Organization beliefs

Conceptualization of the new product should happen upon a fundamental foundation that characterizes the belief of the Organization. The belief that eventually dictates what the product should stand for, why does it exist and how it is intended to achieve the desired functionality. Food for thought, what does great companies like Apple, Google, Facebook, Amazon, Netflix (or even older companies like  Toyota) etc. believe in, are n’t their products direct reflection of what they believe. Therefore, every new product built should embody the beliefs and the new product vision should be a reflection of those beliefs.

What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great Products’.

In the words of Tim Cook, following are the values that define Apple.

We believe that we’re on the face of the Earth to make great products.”

 We believe in the simple, not the complex.”

 We believe in saying no to thousands of products, so that we can really focus on the few that are truly important and meaningful to us.”

– Tim Cook

 

 Values are rather action words that are born out of beliefs and purposes. Are n’t the above-stated values provide a foundation for how Apple build and evolve its products? Therefore, any new product idea conceived in Apple should adhere to the above beliefs

  1. Can the new product idea transition into a great product?
  2. Does the new product idea epitomize the principle of simplicity?
  3. Can the new product idea be transformational for the Organization? Can this idea be the next big bet?

It is not about building unique products, but building products uniquely that no one else dared to build so. There are limitless possibilities for building products uniquely, If Organization believes in something unique and if it has the commitment and conviction to stand for what it believes in. iPod is not a unique product, it entered the market after the market was flooded with lots of music players. What makes an iPod unique is in its approach to building a simple and elegant music player that had powerfully integrated the device, software (iTunes) and music unlike any other device has done before or done after. Apple did follow similar unique approach for iPhone too and I believe they will do it repeatedly for any product that they will ever conceive in future.

It is not about building unique products, but building products uniquely that no one else dared to build so

 

Any new product that is ever conceived should pass the belief test, everything else that is associated with the conceptualization of the new product (idea validation, product-market fit, business review, and new product approval) are mere transactional. Product Manager had to take care of those transactional items as well, but passing belief test will hold the key for the new product success as it will transform the entire new product development from a transactional engagement into a relational engagement. How does entering into a relational engagement makes any difference?

 

Transactional vs relational engagement

Simon Sinek thoughts on ‘Start with WHY’ are very profound that it should find its place in identifying the belief behind the new product. When Product Manager embarks on the journey of building the new product – (s)he should start her journey with a belief that lays the foundation for building the new product, a foundation that succinctly articulates why are we building the new product both from the perspective of Organization and customers. Product Manager should articulate the bigger purpose of building the new product, through creating a vision of the world that does not exist yet. The vision that can unambiguously communicate how the new product will transform lives of customers thereby helping the Organization scale greater height.

Golder circle

Simon Sinek has talked about 3 levels of engagement How? What? and Why? as part of his Golden Circle concept that explains each level of engagement.

When the focus is only on WHAT the new product does? and HOW does it does? The Organization is creating a transactional engagement among all stakeholders both internally and externally sans any purpose.

When the focus is on WHY? The Organization can succinctly articulate its belief and the purpose of its existence. The belief of Organization will lay the foundation for building all new products, a foundation that defines why we are building the new product both from the perspective of Organization and customers and a foundation that can also define how to build and market the new product. The belief imparts the purpose within each stakeholder, so all stakeholders know why they are doing what they are doing. Revenue, growth etc. will not define the belief or purpose. All those elements are by-products of the belief or purpose.

Transactional Engagement vs Relational Engagement

It is not what we make or sell. It is what we believe makes a lot of difference both internally and externally. Belief is contagious and it would spread across to every stakeholder involved with the new product – who sells it, who builds it, who markets it, who supports it, who evangelizes it, who conceptualizes it etc. unifying everyone with a common purpose and vision. There would be now absolute clarity on why we are doing what we are doing. So everyday battles that all of us fight will be around identifying how we can collectively realize the vision of the new product instead of being skeptical about what we are doing. Everyone will be a guardian of the new product vision and struggle to realize it.  There will no more be voices that utter – are we doing the right thing. However, voices will instantaneously raise when there is a deviation from the new product vision, which eventually implies that there is a potential conflict with the belief and purpose as well.

It is not what we make or sell. It is what we believe makes a lot of difference both internally and externally

 

In a transactional engagement, employees know what they are doing albeit with little clarity on why they are doing what they are doing. There is also little clarity on where they are heading. They come, they work, and they go with lots of ambiguity in direction and purpose. Under such circumstances, each employee is a mere foot soldier acting upon certain instructions and when they had to make certain hard choices, they always falter, because employees did not embrace any purpose or values.

On the contrary, in a relational engagement, the belief and purpose will define a set of values (refer to Apple example provided earlier) and those values when imbibed into the DNA of each employee will give them enough knowledge on how to react in any situation by upholding those values. The decision-making will be flat and it does not always have to traverse from top to bottom. Employees always have best knowledge and wisdom to take a decision. Organizations make better products and survive longer if employees take decisions. However, Organization should aid them with guidelines. Belief and purpose are the only way to provide guiding principle or tenets for the decision-making process.

Organizations make better products and survive longer if employees take decisions

 

Look at Walt Disney’s purpose – ‘We create happiness’. Irrespective of their business, they believe in creating happiness. When customers start believing in Walt Disney, start believing in their ability to create happiness, they patronize their products irrespective of movie or theme park. Even employees of Walt Disney will use the purpose and belief of creating happiness as the foundation for conceptualizing new products (movies or theme parks) or evolving any of their existing products (probably theme parks).

Transactional vs relational engagement does not affect internal stakeholders alone. It does influence the way customers perceive about the Organization, perceive about products. It even influences the way customers’ interfaces with Organization and makes a buying decision.

 

So, Did you find your WHY?

When Organization finds its WHY? It is defining the future that the Organization is attempting to create, it is leading the change, and it is envisioning a new world. The new products are merely facilitating the future. When customers understand the WHY (i.e. purpose), they do not see products they see the future. Doing so, Organization is not selling the product it is selling the future. Customers get a palpable sense of the world that does not exist yet. Finally, customers will find something promising. So please do not wait, let us find WHY? to pave way for building a great product.

When organization defines its WHY? It is defining the future that the organization is attempting to create, it is leading the change, and it is envisioning a new world

When customers understand the WHY (i.e. purpose), they do not see products they see the future

 

In a transactional engagement, the horizon is blurred. None has the bigger picture and overall direction. Thereby interactions happen at a product level, at a feature level. Interactions and discussions always happen relative to what others do. Competitors do it, so we need to do it better. Customers require it, so we need to accomplish it. Multiple conflicting priorities pull everyone in multiple directions without any unifying purpose and direction. Choices of customers, competitors, partners etc. will influence our directions and purpose. Finally, Product Manager will lose sight of what really differentiates the new product.

How often has a Product Manager noticed following comments when interacting with customers – I see something missing in your product that is available in competitor products, the product does not follow standards, I don’t know how it will add value to my business, your product is too pricey – I get competitor products for cheaper price, competitor is offering more etc. What those conversations mean to all of us, more specifically to Product Manager, the engagement with customers is merely transactional. In a transactional engagement, we will always be at the mercy of someone who can yield influence with customers. If the new product should not go through those conversations and if it should not be influenced by external stakeholders, then start with WHY? and articulate to your customers, so they believe in what you believe.

Why do you think people buy Tesla? Do people buy Tesla because they believe in the vision of Tesla to build powerful electric cars? Do they buy Tesla looking at the specifications of Tesla models, convinced about the underlying technology and technically impressed at the built of Tesla? I bet that majority of customers belong to the former category. When customers start believing in what Organization believes in, they trust the ability of the product to redefine future. Details of the product will not dominate any conversations with customers. Customers do take pride in associating with such Organizations and its products. They take pride in being part of the journey that transforms the future.

Defining WHY? is essential but what is more important is the commitment and conviction to deliver.

 

Commitment and conviction

Organizations should believe in something that is unique and they should have commitment and conviction to deliver. Exploration is the first step in identifying a belief, which is bold. Boldness in belief does not take us anywhere without a stronger determination for execution. Any fundamental change affects three parameters (i) people, (ii) process and (iii) business. All those three parameters should align with the belief and aid in flawless execution. A candid introspection of the current state of the Organization, what events or actions lead to the current state, and where the Organization intends to head from now can help identify what changes are required to the following three parameters (i) people, (ii) process, and (ii) business. Any form of history always fascinates me and it definitely offers some concrete knowledge on how to build our future based on our past actions. On those lines, I want to quote the words of Andy Grove – Author of ‘Only Paranoids Survive’ and Ex-CEO of Intel.

I have seen far too many people who upon recognizing today’s gap try very hard to determine what decision has to be made to close it. But today’s gap represents a failure of planning sometime in the past.”

– Andy Grove

 

To get the buy-in of everyone internally, Organization has to show the sense of urgency on why we need to transform now. The urgency has to be articulated to employees, shareholders etc. There is also need to articulate – What is in it for everyone – What is in it for employees. It is not always about monetary benefits. Sometimes, there is a need to articulate the bigger purpose. The inclusive approach will make employees feel that they are playing a bigger role in driving change. Shareholders should also understand what is in it for the Organization. They need to understand the results of transformation and why defining a belief would work. People embrace change only upon realizing what is in it for them.

People embrace change only upon realizing what is in it for them

 

Customers and employees do not instantly believe in what Organization believes in. It takes time. Until then Organization should walk the talk and exemplify its belief through its execution. Otherwise, it would be tough to gain the trust of both employees and customers. Belief is contagious only when more advocates believe in what Organization believes in and who can radiate the belief to others on behalf of the Organization.

Call for Action

If you have not defined ‘THE Why’, do it today. Start by identifying what does your Organization believe in and how it can articulate the purpose of the product. If you agree with my views or if you have different point of view, please drop your thoughts in the comments section below.

 

Step-by-step guide for ROI computation of new product

ROI computation of the new product after determining the pricing and the model (SaaS or a perpetual model) is a simple sequence of steps. Product Manager with a flair for mathematics would get rid of this phase with utmost ease as long as (s)he is able to forecast units sold for each quarter for the entire lifetime of the product. Yet, some of us falter as ROI computation is not an everyday activity. So through this blog post, I have tried to provide a step-by-step guide for computation of ROI of the new product. To compute ROI for any new product, we should determine the following.

  1. Revenue estimation
  2. Cost estimation
    1. Operating costs – Cost of engineering, Capital expenses for buying equipment
    2. COGs – For HW products
    3. Royalty payments for IP (If applicable)
    4. License costs – If the new product incorporates SW of other vendors
    5. SG & A –SG & A covers sales, marketing and other administrative expenses associated with the new product. Standard mechanism is to calculate it as fixed % of overall revenues.
  3. Cannibalization impact
  4. Operating Margin
  5. Cash flow
  6. Breakeven or Payback period
  7. NPV (Net Present Value) of all future cash flows
  8. IRR (Internal Rate of Return) of all future cash flows

For better illustration, let us assume the lifetime of the new product as 3 years and it took 1 year to develop the new product. Duration of a year is for conceptualizing the idea, validating the idea, building the product and finally, launching it. Completion of product validation through MVP process also happens within the duration of a year. Even though revenues start flowing from the 1st quarter of a 2nd year, the ROI calculations should happen from the 1st quarter of a 1st year, as costs will be incurred for development of the new product and there will be capital inflow during the period. It is essential to include 1st year to measure negative cash flows and calculate payback period.

Important milestones for illustration

  • The start of product development – Q1 Y1. The 1st year includes all the activities related to product development – Idea validation, business review, product development, product development, MVP validation etc.
  • Product Launch – Q1 Y2. The launched product could be termed a minimum valuable product that customer prefers to buy. The sales of the new product happens from Q1 Y2

Therefore, all calculations that I will do going forward will be done for 4 x 4 (4 quarters for 4 consecutive years)

 

Revenue estimation

Estimate the revenues for the perceived duration of the lifetime of the product. Ideally, I would suggest Product Manager estimates revenue based on a likely scenario. Later we can determine the worst scenario and the most optimistic scenario as % of a likely scenario. Most financials are computed on a quarterly basis, so let us follow the same standards to estimate the sales on a quarterly basis from the first quarter of enabling sales for the new products. There is a possibility to turn on pre-orders for few products before the actual launch. In such case, Product Manager should consider the date of enabling pre-order for estimating revenues and not use the actual launch date of the new product.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Units
List Price / Unit
Discount %
Product Revenue

Table 4 – Units forecast of the new product

Formula

 

 

Cost estimation

There are two types of costs incurred during the entire lifetime of the product (i) variable costs and (ii) fixed costs.

  • Variable costs vary with a number of products sold to customers. For HW products, variable costs are incurred as soon as they are manufactured. However, for calculating ROI, it is ideal to account for variable costs after selling each unit. The costs of inventory are accounted as sunk costs after killing the product and taking it away from the market.
  • Fixed costs are costs incurred in developing the new products and they are independent of product sales. The product reaches breakeven when the revenues compensate the fixed costs.

Variable costs of the new product are

  1. The cost of SW license added to the new product – The new product can include any SW from OEM vendors. The cost paid to vendors is proportional to the number of products sold
  2. COGs (Cost of Goods Sold) of the product – Applicable for HW products
  3. Royalty payment, cost of an Intellectual Property of an external entity

Each unit of the new product sold incurs the above cost. Always calculate per unit variable cost as the sum of all applicable costs listed above.

Fixed costs of the new product are

  1. Cost of equipment required for the new product development
  2. Engineering cost incurred to build, validate and support the new product.

The above costs can incur either once or at regular intervals. The above costs are independent of the number of products sold and they do not vary with the amount of sales.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Units
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin
Gross Margin %

Table 5 – Product revenue of the new product

Formula

Please be aware that only direct product costs are included in calculating gross margin. Fixed costs that that includes engineering cost and expenditure of capital assets incurred due to buying equipment to aid the new product development are not including for calculating gross margin. In addition to those costs, it is essential to account few other operating expenses while calculating operating margin

 

Any cannibalization impact?

Consider the product revenue of any existing products that the new product might possibly cannibalize as a cost.  Forecast how many units of existing product, do the new product cannibalize each quarter. Estimate the product revenue as outlined in Table-5. While calculating the net margins of the new product for each quarter, consider the product revenue of the cannibalized product as cost.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Units
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin

Table 6 – Product revenue of the cannibalized product

Total product revenue is the difference between the product revenue of cannibalized product and product revenue of the new product.

Formula

Using the above equations, I further proceed to compute the operating margin after accommodating the cost of cannibalization.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Gross Margin %

Table 7 – Net product revenues of the new product

 

Operating margin

SG & A is the other major costs incurred by the new product. All expensed incurred for sales, marketing and administration of the new product are tagged under SG & A. In general, fixed % of revenue is allocated to SG & A. Please be aware of all the operation costs tracked in your organization. The majority of operating costs are calculated as fixed % of product revenues. For SG & A, let us assume SG & A spend as 10% of overall product revenues. Account fixed costs due to an expenditure of capital assets and engineering cost while calculating operating margin.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Capital Assets
Engineering Cost
SG & A
Operating Margin
Operating Margin %

Formula

 

Cash flow

Cash flow indicates the amount of cash inflow after deducting all expenses from the product revenue.

Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 Q4 Y4
Operating Margin
Capital Expenditure
Cash Flow
Cash Flow (after Tax)
Cumulative Cash Flow

Cash flow is mostly same as operating margin unless there is a need to account for any additional capital expenditure that was not accounted earlier. The early investment on the new product proposal was not consciously accounted, as it will be later spent on engineering, buying equipment etc. Those costs are accounted anyways. Otherwise, we will double account the same money.

Formula

However, if there is any capital expenditure that we have not accounted until now should be accounted in cash flow calculations, the formula is

Breakeven or payback period is the quarter during which the cumulative cash flow turn positive for the first time.

 

NPV (Net Present Value)

The entire lifetime of the new product is 3 years. Therefore, organization earns revenue on the new product for 12 consecutive quarters. NPV indicates the current value of the sum of all future cash flows (both positive and negative) after deducting tax.

Use NPV formula in excel to calculate the NPV of both operating margin and capital expenditure.

  • NPV of Operating Margin = NPV (LendingRate/4, Operating Margin of Q1Y1: Q4Y4).
  • NPV of Capital Expenditure = NPV (LendingRate/4, Capital Expenditure of Q1Y1: Q4Y4).
  • NPV of Cash Flow = NPV of Operating Margin – NPV of Capital Expenditure

Use the standard applicable lending rate and calculate the rate for a quarter.

 

IRR (Internal Rate of Return)

IRR is the rate at which the net present value of all future cash flows both negative and positive is zero. IRR is a measure of attractiveness of investing in the new product. To calculate IRR, use IRR formula in excel.

  • IRR = IRR (Cash Flow of Q1Y1:Q4Y4) * 4

Sometimes, we might have to present 3 scenarios for projecting ROI

  1. Less Optimal – This is a worst case scenario for the new product
  2. Optimal – Optimal situation and which is most likely to happen and
  3. Most Optimal – Best scenario for the new product.

Product Manager can draw a scenario analysis to identify what factors would lead to each of those three scenarios. However, for estimating ROI for three scenarios, I would probably do it for an optimal scenario. For any scenario, estimating units forecast is the beginning. For less optimal and most optimal scenario, we can compute units forecast as % of units forecasted for an optimal scenario. Probably, I can use 80% for less likely and 120% for a highly likely scenario. After estimating units forecast, diligently following the above steps will help Product Manager compute all the required data for measuring ROI of a new product and build a financial summary for all the three scenarios.

Financial Summary
Scenario Less Likely Most Likely Highly Likely
Product Revenue
Variable Costs
Gross Margin
Gross Margin %      
Capital Assets
Engineering Cost
SG & A
Operating Margin
Operating Margin %      
NPV      
IRR      
Payback Period      

Table 7 – Financial Summary

The above table summarizes the entire elements related to financials of the new product. CFO or VP Finance will be interested in checking whether NPV is attractive and IRR is above the expectations of Organization. During the business review and later for pricing approval of the new product, Product Manager will use the financial summary to summarize the overall attractiveness of the new product.

The excel sheet to perform the above ROI calculated could be downloadable from www.ProductGuy.in/The New Product – ROI.xlsx.

Desperation Index: How desperate are your B2B customers to buy your product

If you are Product Manager managing a B2B product, have you ever consciously thought about the overall budget allocation by B2B customers to buy products that can ensure continuity in business, manage operations, cut costs, increase profits etc. Did you ever managed to identify what % of the budget is allocated to purchasing your product, what is the priority for the need addressed by your product in relation to other needs of customers? Measuring desperation index provides answers to those questions. Customer budgets are limited and many products do fight to get a small share of allocation. Higher the desperation index, there is a high probability that your product will definitely get a pie of budget allocation and as the desperation index goes lower, your product might get little or nothing. So it is essential to measure the desperation index and strategize to keep it higher always. I am borrowing Maslow’s hierarchy of needs to better measure desperation index and to understand its implications

Maslow defined the hierarchy of needs for human beings. The hierarchy defines needs in a pyramid structure where the needs at the bottom are the most important needs. Human beings meet those needs first before proceeding to other needs in the hierarchy. For human beings, food, shelter, clothing, financial security, love forms the basic needs. Probably communication comes next in Internet era. Without meeting those needs, human beings do not normally attend to other needs in the hierarchy, probably buying a car. While validating the new product idea, especially in a B2B segment, it is essential for a Product Manager to define a similar hierarchy of needs for a B2B customer segment to understand the desperation index of customers to satisfy the need addressed by the new product in relation to their other existing needs. Doing so, Product Manager can understand the relative priority of his product from the perspective of customers.

The B2B customer segment has lots of needs primary among them being profitability, shareholder relationship, employee connect, social responsibility etc. In order to fulfill those needs directly or indirectly and ensure continuity in business, customers buy products for office automation, payroll, email communication, sales and leads tracking, collaboration, connectivity, data center etc. Product Manager has to identify all those needs and define a hierarchy of those needs. Later should ascertain the level at which the need addressed by the new product idea is positioned. Customers, while expressing their willingness and affordability to buy the new product will respond in isolation without dwelling too much into their buying economics. However, when customers either allocate or estimate budget for actual purchases, they will prefer buying products at the bottom of the pyramid and will go upwards to satisfy other needs. Product Manager has to ensure that customers’ budget does not dry before reaching the level marked by the positioning of the need addressed by the new product. If a majority of customers could not reach that level, then the new product hardly stands any chance for survival.  Product Manager might have to either strategize to push the need towards the bottom of the pyramid by articulating the value that the new product could bring to customers’ business or gracefully discard the idea of building the new product. Either way, Product Manager has to consciously identify where in the hierarchy, does the need addressed by the new product is positioned and ascertain whether the new product has any chance of survival.

Hierarchy of needs will indicate the desperation index of customers to satisfy the need addressed by the new product in relation to their other existing needs. Customers will start buying products in the descending order of desperation index. The product that addresses needs with higher desperation index is at the top of customer purchase list. Purchase list will contain an exhaustive list of products that customers purchase to address their entire business needs.

The presence of need addressed by the new product at the bottom of the pyramid does not essentially guarantee success. It will only provide an opportunity for survival. Whereas survival will further depend upon how efficiently the new product is addressing the need. In addition, effective positioning of the new product among target customers, prudent pricing of the new product and optimal ways of selling the new product will also determine the survival instincts of the new product. Formulating a pyramid outlining the entire hierarchy of needs and later identifying the layer in which the need addressed by the new product is positioB2B Hierarchy of Needsned can also help Product Manager ascertain the impact to sales during a recession and financial slowdown. Especially during those tough times when customers drastically cut the budget, using the pyramid of the hierarchy of needs,  Product Manager can easily identify what needs do customers might be willing to forego.

Seth Godin has proposed the pyramid for the hierarchy of needs for B2B sales. I am providing it as a reference for Product Manager to define their own hierarchy of needs based on their understanding of their B2B customers’ needs. It is essential to identify an exhaustive list of needs that are on the purchase list of target customers and organize them in the pyramid in accordance with the desperation index of target customers for each need. After constructing the pyramid, Product Manager could validate it by observing purchasing patterns of customers. Purchasing patterns of not specific products but entire products in the purchase list.

Cross pollination of agile and waterfall

Withstanding all the hype surrounding agile, we did follow waterfall model while we built the new product. Agile does not work for all kinds of products even though waterfall model had its own flaws of not allowing the possibility to modify the requirements after entering development phase. So in order to introduce agility within waterfall model, we integrated both agile and waterfall. This blog talks about our experiences of experimenting with a new methodology combining both agility and waterfall. The below excerpts are from my eBook – ‘Building New Product – Experiences of a Product Manager

Our traditional approach to product development has always been the waterfall model. Nevertheless, while we embarked on our journey to build the new product we built the product upon the foundation of waterfall methodology while introducing agility within it. The ability or willingness to experiment with processes or methodologies should be fundamental for any new product development. The experimentation of processes or methodologies can occur when we know why we are doing what we are doing. There should always be a fit between the product and its development methodology, alike product-market fit. If we follow herd mentality and religiously follow a methodology without realizing why we are doing what we are doing, there will be hardly any scope for candid introspection of whether the product and its development methodology have the right fit.

Agile - WaterfallWe never consciously discussed altering waterfall and introducing agility within it. Program Manager naturally adapted the waterfall model to accommodate agility while we had several assumptions to validate, unknowns to eliminate and risks to mitigate. During the course of product development phase. There were never any serious discussions to brainstorm how to integrate both agile and waterfall development methodologies. The objectives and constraints of product development phase naturally triggered our Program Manager to combine them. Real kudos to our Program Manager to introduce agility within waterfall model. It is easy to follow stage gate process to ensure that we complete one stage and move to other. However, while we can only partially complete a stage and move to next stage. Later reverting to earlier stages based on the outcome of a current stage, it is extremely difficult to track dependencies across stages. Let me brief what we did.

For an enterprise product, the architecture of the new product is crucial. I can split the product into two blocks. Architecture block and product functionality block. Redesigning the architecture of the product is always costly and it is as good as developing a new product. Further, the choice of an HW is heavily dependent on the architecture and choice of product architecture is dependent on the HW. Both are mutually dependent. There is a necessity to ensure that HW and architecture can allow the software (i.e. functionality block) to scale as needs of customers evolve with little or no change to both the elements. Why are we putting so much emphasis on product architecture? I once came across a tweet that states every scale has an expiry date. True to those words, software has to scale in future as customer needs evolve and product architecture should support such scale requirements in future with little or no changes to product architecture. Certain elements of product architecture are rigid and it is not possible to modify it as new needs arise. Therefore, it becomes crucial to building a product architecture with a hindsight of how customer needs evolve in future. I did vehemently establish the fact several times in this eBook that the new product should cater to needs of tomorrow and not just for needs of today. Building MVP is not viable to identify needs of tomorrow while it is a viable option for identifying needs of today. Developing customer insights along with identification of factors that can influence the evolution of technology, the evolution of the market, the evolution of customer needs are crucial for anticipating probable needs of tomorrow. Clearly, for enterprise products where architecture can play a big role in determining the success of the new product and where the design and development of architecture happen upfront, agile is counterproductive. Incrementally building product architecture is a grave mistake. However, Program Manager introduced agility in building functionality blocks that address actual customer needs.

During requirements phase, we did outline all assumptions, unknowns, and dependencies across requirements of both product architecture and product functionality. The first priority was to eliminate all unknowns and validate all assumptions surrounding the design of product architecture. The design was mere theoretical until we start building it. Therefore, there will be many assumptions primarily around the ability of product architecture to meet scale requirements. To validate all those assumptions and eliminate unknowns, we constructed hypotheses. On those lines, we also constructed hypotheses surrounding product functional requirements. The product development happens in an interval of 6-8 weeks called DTHOs. Our 1st priority was to eliminate unknowns and validate all assumptions related to product architecture in earlier DTHOs. Dependent products requirements were refined based on the outcomes of those DTHOs.

 

Hypotheses of Product Architecture
Hypotheses Associated Requirements Dependent Requirements
H1 R1 R11
H2 R2 R12
H3 R3 R13
H4 R4 NA
H5 R5 NA

 

Hypotheses of Product Functionality
Hypotheses Associated Requirements Dependent Requirements
H6 R6 R14
H7 R7 NA
H8 R8 R15
H9 R9 R16
H10 R10 NA

The list of hypotheses surrounding both product architecture and product functionality has provided an indication to Development Manager and Program Manager on two aspects. First, the set of functionalities or requirements (R1…R10) that engineering team should implement during the initial DTHOs for validating hypotheses. Second, the set of functionalities or requirements (R11…R16) that engineering team should delay until validation of hypotheses (H1…H10). Delayed functionalities or requirement are later implemented depending upon pivot or preserve scenario in accordance with the outcome of validating each hypothesis.  PRD has clearly articulated the list of incomplete requirements. As initial DTHOs validated hypotheses (H1…H10) through implementing requirements (R1…R10), I refined all dependent requirements (R11…R16) implemented in subsequent DTHOs. The dependent requirements are mostly functional requirements that are refined after validation of hypotheses related to both the requirements of product functionality and product architecture.

One example of a hypothesis is – Ability of the product to meet throughput scale requirements (Hypotheses – H1). The PRD had a clear requirement for the product to deliver 60 Gbps at an average packet size of 512 bytes while maintaining low latency. The conventional wisdom is to measure and report maximum throughput at an average packet size of 512 bytes. Engineering team did validate the hypothesis by building the entire product but performing sizing through simulation. We identified during hypothesis validation that 60 Gbps is achievable albeit with a higher packet size. As I had indicated earlier, marketing team later did lots of analysis, found out the average packet sizes in customer networks is much higher, and we could conveniently defy the conventional wisdom. We never froze entire requirements. Depending on the hypotheses validation, dependent requirements were refined during the course of the new product development introducing agility within waterfall model.

The biggest criticism of waterfall model is that it always heads in one direction. However, we did introduce agility to shift our thinking back and forth between development, design, and requirements. Requirements (R11…R16) were kept open and refined after corresponding hypotheses are validated. We clearly introduced a loop containing product requirements, product design, and product development until we validated all the hypotheses. However, following a strict waterfall model, we had to build a foundation for product architecture upfront unlike in agile before going in a loop containing requirements, design, and development of product functionality. Such model is required for enterprise software products until we find out a methodology for modularly building product architectures for complex systems. Modular architecture should eliminate rigidness facilitating incremental additions to product architecture without the need for redesigning the entire system.

I really feel bad that some of the Product Managers hide their inefficiencies under the veil of methodologies such as Agile, MVP etc. Those are excellent methodologies drafted with good intentions. Nevertheless, those methodologies are more abused than used. MVP formulated by Eric Ries is an excellent way to incrementally build the product through an incremental process of build, measure and learn. Does it mean that a Product Manager should learn every aspect of product requirements through MVP? When it gets difficult for a Product Manager to comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of the product, it will unnecessarily delay product development. There is always a necessity to strike a balance which I find missing. Further, in the case of enterprise products that have a direct effect on customer’s business, the customers will not be ready to validate it thoroughly. While building complex products for enterprise customers, it is always crucial to do extensive customer research and draft those details in PRD to get the bigger picture of the overall product. User stories do not communicate bigger picture. I can definitely bet if I ask for a PRD, some might even perceive me as a person from the dinosaur age. I am not showing my indignation on everyone. Probably, just a handful of them. My request is to embrace methodologies and process, comprehend them thoroughly and adapt them to suit your new product development. Always find the right fit between the product and its corresponding methodology.

Every incumbent product has vulnerabilities

What does success stories of Tesla and Waze teach every Product Manager?  Every incumbent product is vulnerable and there is an opportunity to beat even awesome products.

Tesla Sales

How many of us would have believed that there is a possibility for a new player to emerge (leave alone succeeding) in the luxury car market, beating the likes of Audi, BWM, Mercedes, Lexus, etc? Yet, Tesla zoomed to the top beating the engineering, luxury, speed, performance, and safety of luxury cars built by Audi, BMW, Mercedes, etc. While sales of every other luxury carmaker were declining, Tesla managed 50% YoY. The phenomenal growth of Tesla when the growth of the entire market was actually declining.

Tesla clearly shows that they have defied every conventional wisdom of building products. Elon Musk has shattered existing benchmarks for building the new product. The first element that an investor would look for while building a new product is whether the target market is a growing market. Similar logic applies to Waze as well. Investors would be interested to know whether the new product is addressing a tangible gap and whether there is a place for an alternate product. How many of us would have had the brilliance to spot the white space in navigation products and boldness to overcome Google Maps. Waze did it, Waze managed to build an amazing navigation product preferred by lots of users over Google maps. I could not imagine someone building a better navigation product than Google considering navigation product require lots of work and even Apple failed in its attempt to build an awesome navigation product.

Those examples are testimonials to the fact that it is highly unlikely to build awesome products adhering to existing benchmarks. Conventional wisdom always believes in building a new product in growing markets and in markets where there is a palpable gap of unaddressed needs. The Conventional wisdom of building products is accrued naturally through precedents set by earlier successful products. Astronomical valuation of Facebook during its initial days based on its active users instead of its actual revenues has set a precedent for every other internet company to focus on user acquisition and not on generating actual revenues. Someone should set the precedent first before it becomes a conventional wisdom. The Majority of great products have set the precedent and not followed any existing precedent set by other successful products. Tesla and Waze have also set a new precedent going against conventional wisdom. They have proven that every incumbent product is vulnerable and there is always an opportunity. However, it is not an opportunity that is visible in plain sight. All it requires is a keen eye to identify white space, bold thinking, appetite for risk, impeccable execution to beat incumbent products.

The above contents are part of eBook – ‘Building New Product – My Experiences’

 

Building New Product – Experiences of a Product Manager (free eBook)

I am glad to end 2016 with  completion of 3rd edition of my eBook – ‘Building New Product – Experiences of a Product Manager’. I released 1st edition of the eBook towards end of 2014. Ever since, I did a critical review of my work to check whether i had provided enough information in my eBook, accordingly evolved it into 3rd edition. I did so, by holistically reflecting on my experiences of building the new product not just by introspecting what i did better but also being critical about where did i go wrong and what i could have done better. I leveraged those insights to provide more actionable information on how to build great product that is:

  • Built on a foundation of strong product vision that ultimately defines the purpose and objective (WHY?) behind the new product.
  • Built in alignment with real needs of real customers and as desired by those real customers.
  • Built not just for needs of today but for needs of tomorrow.
  • Built with all essential attributes that drive customer preferences towards the new product.
  • Built with focus on doing one thing (that drives customer preference) awesomely right instead of doing everything right.
  • Built with basic premise of think bold, think future unconstrained by any limitations.

I really appreciate if you could take a look and drop your thoughts or comments.

What is the right product management culture

One important tenet, that I believe as a Product Manager is that

Product Manager should stand for what (s)he believes is right for the product and do what (s)he believes is right for the product. I a firm believer in that tenet.

Why the above tenet is so important? Product Manager is a glue that connects every entity (Engineering, Design, Sales, Account Team, Marketing etc.) and thereby has a responsibility to ensure that everyone is walking the same direction towards the same goal. Hence it is vital for Product Manager to stand for what he believes is right for the product and do what is right for the product. I am not talking about shifting power, I am talking about facilitating to do what is right. However, it does not evade the responsibility of others to stand for what they believe is right. To do so, everyone need to have same shared vision and work collaboratively for the common good without letting people with higher power to forcefully enforce ideas irrationally.

But, how do Product Managers can uphold such a tenet and practice it in an Organization. Only through a right culture. So, why is culture so important and how it is related to upholding and practicing a tenant.

Importance of Culture

Culture in short is a way of doing things in an Organization. Culture is not a rule book but a set of guidelines that outlines how an Organization would behave. Having a culture that is strongly and consistently imbibed into each employee of an Organization will evoke a similar response for any given situation. Without a culture, Organization is failing to set those guidelines for every employee to share a common belief. Every Organization embrace diversity in hiring people without any discrimination on the basis on age, sex, creed, race, religion, color etc. However, every employee should share a common belief that characterizes purpose and belief of an Organization. If Organization believes in innovation and if it believes in customer excellence, it should be reflected in Organization culture. Without a strong culture, it is not possible for employees to share a common belief and therefore nothing will be deterministic when things go wrong. Organization is only sowing seeds for a failure. Without a strong culture, Organization is not what it says it is.

For better reference on Organization culture, there is nothing better than slides on Netflix culture on slideshare:

Organization culture should directly or indirectly promote a strong product management culture too. The aspects of what culture should be cultivated in an Organization is determined by its goals and beliefs. Similarly, the goal for a right product management culture is to facilitate Product Managers to stand for what they believe is right for the product and empower them to do what they believe is right for the product. Right product management culture is required not just to influence Product Manager but every entity in an Organization to build and evolve great products that are

  • Built on a foundation of strong product vision that defines the purpose and objective behind the new product.
  • Built in alignment with real needs of real customers and as desired by those real customers.
  • Built not just for needs of today but for needs of tomorrow in alignment with evolution of technology trends, market trends, changing customer needs and their behaviors.
  • Built with all essential attributes that drive customer preferences towards the new product.

Celebrate failure

Mediocrity hampers us from building great products. Employees think mediocre, not because of lack of competence, not because of inability to think bold, but because of lack of intention to set high standards. Employees hesitate to set high standards because of fear of being crucified when failed. Probably another reason for such attitude are those mundane goals characterized as SMART – S ‘Smart’, M ‘Measurable’, A ‘Agreeable’, R ‘Realistic’, T ‘Time Bound’. Great products are built upon a foundation of great idea that seem unrealistic when conceptualized.  So if Organization is following traditional ways of measuring employee performance, it is only paving way for mediocrity. Realistic goals can be set for predictive outcomes, but along the path of setting high standard to build great products, the outcomes can seldom be predictive.

 “I’d rather attempt to do something great and fail than to attempt to do nothing and succeed”

– Robert H. Schuller

Only when employees start thinking bold and make an honest attempt to achieve it, they really know their capabilities, they could really gauge the possibilities. When we are thinking bold, thinking future, nothing is a straight line. All of us have to navigate through lots of uncertainties and unknowns to pivot quickly. Unless Organization celebrate failures and unless it cherishes the ability to fail quickly, it is closing the path to greatness.

On the note of celebrating failure, please take a look at the amazing video of Astro Teller (CEO of X) for this thoughts on celebrating failure.

Reward effort, not just outcome

Traditional ways of evaluating employees’ performance are always based on outcomes. Unfortunately, outcomes do not always directly correlate with capabilities and efforts of employees. Outcomes are more important, but as I had just indicated outcomes do not always depict the real capabilities of the team or its individuals delivering those outcomes. During my days as development engineer, every time I resolve a critical issue for a customer, I will get a flurry of emails applauding my efforts from customers, account team etc. All those emails will finally be followed by a ‘Thank You’ email from my manager. It is only during those occasions that I get an applauding email from my Manager. Luckily, I had wonderful managers, there were hardly couple of exceptions in my entire career.

I often wonder, why does even my manager who can have a close watch on what I am doing have to appreciate me only based on an outcome. There are lots of good outcome with little efforts and not so good outcomes with tremendous efforts. For customers, it is definitely outcomes and the impact it has on business is the only tangible way to appreciate our efforts. Nevertheless, it should not be the only yardstick to measure performance internally within an Organization. I always loathe managers who are outcome based.

Appraisals, performance evaluation of every employee is done in a half-yearly and yearly cycle, but building great products does not happen in such short timeframe. They take time, so just evaluating performance based on outcome is definitely short-sighted. If we had to celebrate failures, we have to start applauding the efforts and not just outcomes. Doing so, Organization provides enough impetus for employees to aim for the sky and yet allows them to fail gracefully without being ridiculed or castigated. Even in case of failure, there is a tremendous realization of various possibilities.

“Failure is simply the opportunity to begin again, this time more intelligently”

– Henry Ford

Data driven

Even though the motivation behind celebrating failure is to inspire employees to set high standards, the other important element is to provide an incentive to fail early and quickly without allowing anyone to hang-on indefinitely until it gets too late.

We always preach fail early and quickly. The primary reason is that we do not want to spend too much efforts and go too far to finally realize we are failing. But then how far is too far. The answer lay in relying on data (both quantitative and qualitative) to analyse how long to persist and when exactly to hit the failure button. For data driven model to be successful, it requires a mindset change, a mindset that does not try too hard to be correct. Data driven model will abstain each of us to remain in a state of prolonged perseverance to hold onto one’s viewpoints without any rationality. There are other inherent advantages of being data driven (i) Every view point or decision has to be backed by data and not just by the highest paid person’s opinion (HiPPO) and (ii) Data will facilitate better ways to measure the efforts, to quantify knowledge gained out of failure and how it can help us to start intelligently again

Embrace criticism

Organization should develop a culture that is not averse to constructive criticism. Why would criticism be seen as bad (i) arrogance or egocentricity – ‘How can my ideas be criticized?’ The problem is due to bad hire who is culturally misfit (ii) insecurity – ‘Oh, my idea is seen as bad, does it reflect bad on my capability’. No idea or thought is perfect at first instance, criticism should have boundaries and it has to be targeted at an idea or a thought and not on an individual. Originators of an idea too should accept possibility of imperfection and embrace criticism to make improvements.

When organization culture promotes customer empathy and follows an inclusive and collaborative approach, it stops paying heed to the ideas and opinions of only the highest paid. Doing so, there will be democratization of ideas and the best ideas that addresses customer needs will win irrespective of who triggers the idea. Customer empathy will let everyone work for the larger good of the product rather than the self. In such scenarios, constructive criticism will be embraced by each employee to build better products.

Final thoughts

Clearly, the right product management culture that can facilitate Organizations to build great product is to have everyone think bold and aim for the sky, shed their inhibitions to fail, crush their egos, embrace criticism and subject their actions to scrutiny.  Above all, another important element is to hire best talent who has right cultural fit.

Hey Product Manager – Did you ever stood up for what you believe

Product Managers are always termed as a CEO of a Product. Some say, it is mere rhetoric. Others argue, it is a classic lie as Product Managers have hardly any authority to move the needle that can propel the Product in the path of success. Nevertheless, I still believe Product Manager is a CEO of the product, (s)he owns. For me, it is less about authority and more about responsibility of doing what is right for the product and standing up for what we believe is right for the product even at the risk of being alienated.

Question to all my fellow Product Managers – How many times, have your ever stood up for what you believe is right for the product.  Have you not stood up before because your organization does not foster the culture of questioning or are you just clueless on how the proposed changes could impact the product? I am not insisting Product Managers to either revolt or take sides, I am just insisting them to articulate their position or viewpoints with strong backing of either quantitative or qualitative data.

An ideal Product Manager by virtue of owning the product, having a broader understanding of the market in which the product operates and with absolute awareness of which customers use the product, why they use it and how they use it should have ability to connect dots to anticipate the impact of any proposed changes. Anyone one else in the organization might not have such a depth of understanding, thereby making it essential for Product Managers to stand up to make sure their voices are heard.

It does not matter if view of a Product Manager is turned-down, what is more important is that the voice of Product Manager should be heard. However, end of the day we take decisions as a team and we should collectively stand by it. I believe we as a team should own it rather than blaming individuals and see how the risks associated with the decision could be ascertained.

If you are not a Product Manager, have you ever come across a Product Manager in your organization who has stood up for what (s)he believes in. If not, then your organization is either not hiring great Product Managers or it is not fostering a right product management culture that can let Product Managers stand up for what they believe in. In my next blog, let me explicitly focus on what kind of product management culture should we instil in an organization.