Product Management Approaches - New Product vs. Existing Product

Tweet

I wanted to compare and contrast the product management approach for a new product vs. an existing product. As a Product Manager, you need to be conscious of which phase your product is at in the product life cycle.

If you are taking up a new job, then it is critical that you keep track of the stages of your product as not all product management approaches will fit to all types of products. Also, different Product Managers are good at different product management approaches.

For a new product the following steps generally take this logical order:

Opportunity Discovery ==> Opportunity Assessment ==> Opportunity Validation ==> Product Discovery ==> Product Validation ==> Finalize Metrics (KPI) ==> Execution ==> Go-to-market strategy ==> Launch ==> Post-Launch Assessment

Opportunity discovery occurs mainly through ideation, where you explore various ideas, but often the founder in a startup or other senior executives in a large company tell you what you need to explore. You are mainly trying to find a customer’s needs, which are either stated and unmet or unstated needs, which your company can solve by bringing a new product to market.

In the Opportunity Assessment phase, you evaluate the product idea to decide whether it has any legs. You want to achieve something quick, instead of writing a long MRD document. For more coverage on the topic you can read renowned Silicon Valley Product Management thought leader Marty Cagan’s blog here. The goal of the opportunity assessment is to evaluate if the company should pursue the idea and if the answer is yes, then assess what it will take to succeed.

During the Opportunity Validation step you are validating your hypothesis with the target customer. If the target customer is not excited about the opportunity, then the necessity of the product is not genuine enough that the customer will eventually pay for a solution.

In the Product Discovery phase you are quickly iterating through various solutions to meet the customer’s need. In this phase you develop a rapid prototype, which you can present to customers for confirmation. In the Product Validation phase, you present the prototype and gain valuable feedback for further refinement.

If the target customer does not resonate with the product, then either one of the following is true:
· You are talking to the wrong user
· Your solution/product does not meet the user’s need
· The necessity is not valuable enough for the user

The first two reasons are fixable, but if you have stumbled upon a need, which is not critical enough for the customer to either use/pursue a solution or pay for it, then you are better off abandoning the idea.
After the product validation phase, you need to define product by using business metrics, with which you can measure the success of the product in the market. Defining success metrics is a separate blog topic in and of itself so I will skip past it for now.

Finally, you need to develop the product. You must create the go-to-market strategy and launch the product. After launching the product you need to measure the product performance against the metrics you have created earlier. It is important to continuously compare against those metrics and iterate on the product features until you are moving the needle on your metrics.

Each of these phases are important individually and are based on where the product is in its life-cycle (development, introduction, growth, maturity, decline), you might be involved in one or more of these activities.

Compare this to the product management approach you will adopt for existing products where you analyze the usage, develop metrics, and build features to meet business goals. Most of these metrics (business or product) will revolve around acquisition, conversion, and retention. Engagement features are part of the retention metrics.

For an existing product the following steps make logical sense:

Usage Analysis ==> Create Metrics (KPI) ==> Execution ==> Launch ==> Post-Launch Assessment

While taking up a new job, it is critical for you to know which product you are going to lead (new vs. existing) and what stage of its life cycle it is at. These two dimensions will help you choose the best product management approach for the given situation. In this blog we covered the differences in Product Management approaches between new and existing product. I will address the differences in product management approach for a product at various stages of product life-cycle in future blogs.

Model Thinking – The Fox and the Hedgehog

Tweet

Someone I love once told me that I overthink everything. Ironically, I started overthinking about why I overthink. After a lot of thought I realized that I try to fit every problem into a model for analysis. Models help me structure my thought process, and help me question my assumptions and communicate my analysis. Most of my thought process is spent in trying to fit the prevailing problem to an existing model, whether it is the Game Theory model, Wisdom of Crowds model or Markov Processes.

“Essentially, all models are wrong, but some are useful” - George E.P. Box

Models do not give you nicely packaged answers. Nor are all the models always right. They help you structure your thought process and help you find a solution. I started studying more about formal models in a course I took from University of Michigan on Coursera by Scott E Page. Scott is the Director of Center for Study of Complex Systems. I read a few of his books, one of them being Complex Adaptive Systems. In this book, I found the concept of Hedgehogs vs. Foxes to be intriguing. This concept seems to coincide with the manager vs. leader arguments I find in literature that I studied in the leadership class during my short stint at National University of Singapore.. In Complex Adaptive Systems, the concept I speak about talks about how the Fox knows many things but the hedgehog only knows one major thing. I focused on analyzing my thinking process and where I fall on the scale of fox/hedgehog. It is interesting to analyze who you are, so that you can stop trying to be who you are not.
 


If you analyze the three circles of the Hedgehog concept, it basically talks about analyzing your passions, your skills and what can give you economic satisfaction and then choosing something, which is the intersection of the three. I wrote another blog on “Anything Worth Doing is Worth Over Doing “which talks a little more about passion and how there is a feedback loop between passion and skills.
 


Philip Tetlock’s book "Expert Political Judgment", talks about idiosyncrasy and how erroneous 'expert' judgments about future events can be. Hedgehogs use only one model, while foxes use many informal models, as shown in the picture below. Isaiah Berlin (social and political theorist, philosopher and historian of ideas, "thought by many to be the dominant scholar of his generation") said, that Hedgehogs have just one, powerful response to a threat: they roll themselves into a ball, and present spikes to possible predators. Foxes, by contrast, draw on many different patterns of general understanding, making mistakes along the way without ever committing to a grand strategy; they have no single response to challenges. These differences between the expert and the generalist are what Tetlock used to name the two ends of the dimension of distinctive 'thinking styles' for future oriented complex problems. His book shows that one of these cognitive styles is superior to the other in predicting events and adapting to new information.
 


People with Hedgehog cognitive style are what I call “single minded people”. They like simple models, which are decisive and result in binary verdicts and are easily replicable. They don’t like multiple scenario models each with a different probability. They need established, uncontroversial models, which have examples of having succeeded in the past. They need approval of their peers and resist any argument contradicting the model. They basically need a sense of closure and finality in order to feel happy.
Foxes on the other hand do not commit to any one model and prefer to calibrate their insights based on many different perspectives. They adapt quickly to unexpected events and are tolerant to the idea of being challenged on what they believe to be true. They thrive in the face of uncertainty, and continuously adjust their responses, rather than sticking to a simple preset plan. Hedgehogs flourish in an environment with minimal uncertainties, while Foxes thrive in chaos.
 


Now, compare this to the theory of Managers vs. Leaders in the corporate world and you will see a lot of overlap. The concept of “targets and accountability” was made by and for Managers, who embody the characteristics of Hedgehogs. Leaders on the other hand, thrive in an uncertain environment much like the fox. Situations like a new product/business or there is a crisis, which needs to be handled by thinking outside the box. Managers are good at following the process that has already been laid out by leaders or improve the process for achieving efficiencies once the business has reached a certain level of predictability or a crisis has been resolved. Managers are good at “keeping the lights on” and will succumb if put in a novel situation or crisis for which they do not have direct experience dealing with.

In Silicon Valley you find three types of people:
1. People who work for large companies
2. Entrepreneurs who begin startups
3. People who work for startups

The first type is what I call Hedgehogs, for they need the predictability and stability of large companies to go about their life securely. They cannot handle waking up in the morning with the uncertainties that come with the world of startup companies. They serve a purpose as these large companies are doing what you call incremental innovation rather than cutting edge invention or innovation. Intrapreneurs are an exception to this, but that is a topic for another blog. Entrepreneurs are Foxes who thrive on the uncertainties of the startup world. They cannot stand the routines of working in a large company, and trust me they will go crazy. People who work for startups are somewhere in middle in that they are closer to Foxes but for various reasons, including lack of opportunity or a great idea of their own, they choose to work for a startup. Most of these guys do eventually end up creating their own start-up.

While Foxes are actively looking for opportunities to address complex problems and are always ready to jump onto the next big thing, Hedgehogs will not be able to recognize an opportunity even when it is presented to them Sometimes, even when explained about the opportunity and rewards, they will analyze the risks associated with it and choose to continue on the conservative path.

Unfortunately the world has become too complex for the Hedgehog’s style and we need Fox-like outlooks to deal with today’s problems. The problem with the Fox’s style is that it does not come with a neat, closed model, defined goals, and easy metrics like the Hedgehog does. It requires gradual iterations to move forward. The fox’s approach responds to new information, continuously re-calibrating and adjusting to the changing circumstances and eventually leading to a superior outcome. Today’s knowledge economy requires Fox-like approach and they intern will create the conditions for the future Hedgehogs to thrive. So, where do you fall on the Fox-Hedgehog scale? How do you deal with complex and uncertain situations? Do you use one style over the other or you use the combination of them based on the situation?

VP of Product Management or VP of Engineering? Reporting structure

Tweet

I always get asked whether the Director of Engineering should report to the Vice President of Product Management or if the Director of Product Management should report to the Vice President of Engineering. There is a third option which is more prevalent in the Silicon Valley:  Product Management and Engineering has its own parallel organization. I have personally struggled with this question a lot as I have navigated through my career.

Product Management is all about the WHAT of the product whereas Engineering is about the HOW. Product management is responsible for defining the product both in terms of its form and its function. Form is fundamentally user interaction design and visual design whereas function is a prioritized feature list which delivers the necessary value to end user. Another way to put it is that Product Management is central for defining a valuable, usable and feasible product. Engineering, on the other hand, is responsible for creating architecture and building/developing the product. It requires an ability to figure out the implementation of the architecture on the product and have the operational excellence to deliver a quality product on time with the given resources. You could say that Product Management is more strategic while Engineering is more operational, however both involve creativity.

A VP of Engineering will not have appreciation for the product management functions and will reduce them to requirement managers, if product managers report to them. Similarly, a VP of Product Management might over-emphasize the product definition aspects, focusing mainly on customer features while ignoring the engineering, technical debt/architecture challenges. Also a VP of Product Management will rarely command the respect of engineers - especially in Silicon Valley.

I think there is no one right answer, but I strongly believe that there is a need for an alternative option:  a new position called VP of Product or VP of Product Development. I would advocate for both the Director of Engineering and the Director of Product Management to report to the VP of Products. The requirements of an applicant to fill this position could come from an engineering or product management background, but I highly suspect that someone who has never delved in engineering could ever be successful in this role. The ideal applicant for this role would be someone who has experience in the engineering field and then later migrated to product management. I think that at least 5 years in engineering and an equal number of years in product management would allow a person in this position to have the technical depth to lead an engineering team while also have the necessary training to think strategically about market positioning. The VP of Products would allow for a middle ground that could command the respect of both the functions and would result in delivering a better product.

I have started seeing this role being defined as above in various technology/internet companies in the last year. I am hoping this trend will catch on and will lead to better products. I will write more about this in future blog posts.

S-curve and personal life

Tweet

S-curve is a sigmoid curve in mathematical terms, but we are not here to talk about mathematics. I have come across the s-curve while studying various domains including marketing, strategy, mathematics, and philosophy. This is a concept I have been intrigued by for a very long time.

If life and business could fit on a linear model, it would be an easy task to predict anything; everything would be so simple. Unfortunately this is not how it works. Cause and effect is not as simple as a light switch where the system reacts immediately.

Let’s first introduce the concept and then we can get into how it is applicable to personal life. Here is the generic form of the curve:

In the fermentation stage there is very little output for a large input. i.e: huge effort may yield only a little in the near future. This is the investment phase of the curve. In the Take-off phase, there is a large amount of output for very little incremental input. This is also known as the pay-off period. In the Stagnation phase, you have reached saturation and incremental output is relatively low compared to the of input.

This concept can be applied in many different fields. In the marketing domain, it explains the lifecycle of adoption of new technology or diffusion of disruptive innovations as shown below:

Diffusion or adoption is relatively slow at the outset but then enters the stage of hyper growth, which typically reaches saturation above 90 of addressable market.

In the innovation strategy domain it explains the performance improvement over time of given technology improvement initiative. It highlights that as you invest on improving the performance of a system, the initial gains are very low compared to the overall investment in R&D. However as time passes, it starts to payoff and the results are steep returns. This image below clearly highlights the time delay aspect of returns in a complex system:

An individual acquiring a new skill can be plotted on the s-curve as well. As show in the diagram below by Juan Mendez, moving up the personal learning curve can be slow at first as you attempt to gain expertise in your new domain. But with time it accelerates to a sudden mastery, this eventually slows down as you stop learning new things and stop enjoying the domain or as Juan Mendez puts it, when the thrill ride is over.

Similarly the s-curve can be plotted for individuals pursuing new goals. Eventually the thrill ride will be over. As you hit the saturation in your pursuits of new goals, you should jump on to a new s-curve. If you do not you still might be okay financially, but you might be less happy and your confidence along with your general well-being will take a hit. In my opinion this is what leads to mediocre existence. It is sad to see so many talented engineers in Silicon Valley fall quarry to this and end up working smaller jobs at large companies with only incremental growth in their careers.

As Saul Kaplan shares: “My life has been about searching for the steep learning curve because that’s where I do my best work. When I do my best work, money and stature have always followed.”

In summary, it is easy to plan life when things are linear which they could be if you want to lead an ordinary career. However the path to an extraordinary career and therefore, existence, is not-linear and our brain eventually requires the dopamine of the unpredictability. This picture makes a compelling case for how to navigate your career and personal growth. In closing, as Juan puts it: “Don’t be afraid. It takes courage to jump from one curve to the next. Staying in the comfort zone is easy, but greatness happens when you escape from it”.

Fear of failure - A motivator for success?

Tweet

I have preached in the past that fear can be the greatest limiting factor in a person's success. You might have heard that entrepreneurs, extreme sports enthusiast, and CEOs alike do not feel fear; this has to do with how they are wired. I personally live by the principle that if you feel fear, then you are going to be averse to taking any risks thereby limiting your success. It reminds me of a joke from the TV series Seinfeld - in which the airhostess, while closing the curtain to the business class section, gives an expression that fundamentally says, "If only you had worked a little harder."

I believe that the true road to success is not just the desire to succeed, but also the fear of failure. 

As I have entered this next phase in my life, I have become much more reflective of my personal philosophies and what made me succeed in some endeavors yet fail at others. I have been thinking a lot more about what motivates me to succeed. What makes me wake up every morning and keep pushing myself to go further? Part of what motivates me is the fear of failure. This makes me wonder, without the fear of failure would I have done everything I could to succeed? If you let fear stop you from pursuing a goal, then it is definitely a inhibitor. However, if it helps you plan and execute better, and motivates you to give 100% in order to succeed then fear can be a powerful thing.

Let’s say your fear for failure doesn’t motivate you enough to get you over the top, and you end up failing. Now what? It is your response to failure, which will eventually define you.  As a leader you are bound to fail eventually no matter how smart you are. If you have not failed then you have not pushed yourself outside your comfort zone. That said you then need to fight back. If one approach does not work, try another. Rather than letting failure stop you, let it prepare you better for the next battle. This will invariably lead you to greater success.

In my experience failure also helps you find out who your real friends are. I tend to test people in small ways. I ask them for help during a small crunch or rough spot even if I can handle it, just to see their response. You can judge a person's character and their dependability in this way. If a person is not available to provide a shoulder when you are down, will they really be there when you are going through a major crisis? The true strength of a relationship only gets tested in the face of strong adversity. Failure also teaches you empathy. It teaches you to be modest. It makes you realize that the most beautiful thing in life is when someone cares about you unconditionally. 

Node.js video tutorials

Tweet

I wanted to create a repository of node.js related videos and tag them for easy learning. I will continue updating them as I find more material.

THE CALLBACK PATTERN by Pedro Teixeira

                         

THE EVENT EMITTER PATTERN  by Pedro Teixeira

                     

Product vs. Engineering Roles

Tweet

I have spent over 10 years in engineering roles (software engineer, engineering manager and architect) and the last 3 years in product roles (product manager, product marketing manager, general manager). As a product manager (at any level) you are defining the WHAT of the product. As an engineer you figure out the HOW of the product. I will dig deeper into each of these roles below and will also try answering questions like “is a product manager role needed in startups?”, “should engineering report to product or product report to engineering?”

As a product manager, depending on whether it is a startup or a large company and depending on the stage of the product life cycle, you will be working on one of the following phases of the product.:

Opportunity Discovery --> Opportunity Assessment –> Opportunity Validation –> Product Discovery –> Solution Validation –> Metrics (KPI) definition –> Execution –> Go-to-market strategy –> Launch –> Post-launch Assessment.

As a product manager you are responsible for product definition which fundamentally means defining the form and function of the product. You are defining what is going to be built, but not how.

In the execution phase, while engineering is developing features for the current iteration, you will focus on defining features for the next, apart from helping clarify the feature description for the current iteration.

Product definition:

Function

Defining a product involves describing which features need to be built during the next development cycle in detail. If you are using SCRUM methodology for product development, you end up writing epics and user stories describing the product features in detail, maintaining a prioritized backlog of product features, so that engineers can pull from the top of the stack until there is no more bandwidth in the current engineering cycle. There are multiple meetings that a product manager can setup as part of the scrum process to communicate the features. During the product planning meeting, the product manager describes the product features in detail and collaborates on prioritizing them in the product backlog. During sprint backlog, the team decides what they can commitment for the next development cycle and the product manager answers any questions related to user stories. Dependencies between user stories are resolved at this stage as well.

 

Form

As a product manager, you are also responsible for defining the wireframes and visual design of the feature (not applicable if the feature does not have any end user facing component). Obviously you are not going to design them yourself. You will work with an interaction designer in the product discovery phase to finalize the wireframes required for the feature before scheduling it in the engineering development cycle. You will also work with the visual designer to add the look and feel (emotions) to the wireframe, but this can technically be done in parallel with the engineering effort. More on this in later blogs.

As an engineer (or engineering manager or architect) you are mostly involved in figuring out how. You are also responsible for (unless you have a dedicated program manager) to commit to the feature as part of the sprint planning meeting, come up with an estimation and deliver the feature on time with an acceptable quality. You are also responsible to work with product manager to get a sign off and deploy the feature to the production (unless you have a dedicated service engineer).

Now lets get back to the original topic of this article. Do I want to be in an engineering group or a product group?  I think this a very personal decision and different people have different opinions. Product definition is inherently a creative job which appeals to many. Engineering gives you the satisfaction of actually being able to implement your ideas and vision. I have struggled with this question for a long time. When I was running engineering groups, I longed for product roles. As a product manager, I feel helpless when I cannot just roll up my sleeves, sit with engineers and develop it the way I think it should be developed. Maybe most of these frustrations are due to dealing with few inefficient engineering managers, but never the less you run into them frequently.

I will side track for a moment to discuss what I mean by product development. A product development group has the following key roles.

1. Product manager to define the product being built.

2. Engineering (including engineering management) to build the product.

3. Architect to define the technical architecture.

4. Designers (both interaction and visual designers) to create wireframes and visual assets.

Each of these roles is self-explanatory and they are all critical for building a successful product.

Back to the original discussion now; after a long and considerable thought, I would rather run the product development group or have the title of Director of Product development than have the role of Director of engineering. That way I can be responsible for both product definition and product execution. Anyone who has engineering background and has successfully transitioned into a product management role, will be a perfect match for this position. This will eliminate the debate whether product should report to engineering or engineering to product. It will bring both the groups into a single umbrella and get the work done faster. The team can focus on delivering a successful product, which is valuable, feasible and usable.

I will talk more about this in the next article. The article is long enough already.