Tag Archives: product management

Systems Thinking #5- Common Leverage & Convergence

When we are trying to solve customer problems it is important that we do not ignore the fact that business outcomes will also rely on defining a great product that needs to be supported by a strong org design that helps align with the flow of the business.

The application of convergent thinking practice ( picked from the design thinking paradigm ) is helpful in such situations for selecting the optimal solution from a finite set of ideas collected from different sources that can solve a discrete challenge quickly and efficiently.

Apply the process of system thinking to identify a finite set of ideas. Then identify common leverage points.

Apply the methods of convergent thinking using the data and information you need to guide a decision or solution.

Leverage the knowledge of subject experts and relevant data to drive systems thinking and provide the team with analysis to bring that information together into an educated decision. Convergent thinking will typically call for speed and accuracy

A decision that drives us to find a common leverage that can lead us to define and commit on all the three axes of customer problem, product, and org becomes a well-informed decision.

Evolving Through Aggregation – Product Thinking

I am quoting here from the great Nobel Laureate Herbert Simon

H. SIMON explains through his famous Hora and Tempus Parable how complexity may have evolved:
“Let me introduce the topic of evolution with a parable. There once were two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently – new customers were constantly calling them. However, Hora prospered, while Tempus became poorer and poorer and finally lost his shop. What was the reason?
“The watches the men made consisted of about 1.000 parts each. Tempus had so constructed his that if he had one partly assembled and had to put it down – to answer the phone say – it immediately fell to pieces and had to be reassembled from the elements. The better the customers liked his watches, the more they phoned him, the more difficult it became for him to find enough uninterrupted time to finish a watch.
“The watches that Hora made were no less complex than those of Tempus. But he had designed them so that he could put together subassemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly; and a system of ten of the latter subassemblies constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the manhours it took Tempus.

I find this has lot of value for product managers to read and glean through. Pick facts through an unrelated systemic explanation as above.

There are couple of questions which I did like product managers to take as a riddle and read through for answers or thoughts :

  • How TO construct strategy as sub-assembly designs to pave a roadmap of evolution of design via aggreations of loosely coupled blocks?
  • How NOT TO consider the sub-assemblies merely as lego blocks bit instead find sub-assembly patterns as more concrete lego bricks made up of blocks ?
  • How TO find balance between increasing complexity and evolution of design to minimize disruption?

These principles would apply to any kind of ecolutionary iniative one would take up and can define impacts that are both technical as well non-technical.

Playing Position Of A Product Manager

We are faced with decisions and trade-offs on a daily basis.  Moreover, we are challenged to ensure that product features, target markets, and technologies align with overall business and strategic objectives.  Projects are advanced based not only on technical merits but also sales, revenue, and profit forecasts.

Product management is one of the most strategic yet least understood business functions in many organizations. The roles and expectations of product management vary considerably from one organization to another. Even within the same company, product management is often carried out in different ways.

This lack of agreement on what product management is may also cause role confusion and miscommunication inside the organization, leading to sub-optimal performance. Foremost role of product management is to help bring process and business savvy to the creation and delivery of products. 

Play out some scenarios and you will see what is happening around you:

  • Traditional consumer companies have always considered product management to be a marketing role, which is why it seems to make sense to put product management there. And it does make sense–if marketing is defining and delivering products. Alas, many technology companies consider the term “marketing” to be synonymous with “marketing communications.” So if the Marketing department is only about delivering products but not defining them, product managers should be elsewhere.
  • For technology companies, particularly those with enterprise or B2B products, the product management job is very technical. This is why we see many product managers reporting to Development or Engineering. However, we’ve seen a shift away from this in recent years. The problem appears to be technical product managers spend so much time writing requirements, they don’t have time to visit the market to better understand the problems their products are designed to solve. They spend so much time building products that they’re not equipped to help deliver them to the market.
  • Very few product managers find themselves in a Sales (or Sales & Marketing) department. It seems clear product managers in Sales will spend all of their time supporting sales people with demos and presentations. The product managers become the sales engineers.

In effect, subordinating product management relegates it to a support role for the primary goal of the department & product managers end up being project managers and Development gofers.

My passing thought would be that it would never matter where product management reports. What matters is how product management is made more accountable and that would mean trying to answer , what does “success” look like for a product manager?

Reflections By Steven Sinofsky

I chanced to read following article Steven Sinofsky on Building Your Product Team  published on the MixPanel blog. It had some great insights  which , I  have captured for my readers and fellow companions who cross their path with product management.

From the above blog

Steven Sinofsky is known as one of product management’s earliest champions. In fact, he was at Microsoft when the company invented “v. 1.0” of the product manager career path.”

While I read through the article , I made this story come out more as my questions in mind as reflections followed by relevant portions from the blog as excerpts.

Why did product manager came into existence?

What is the world beyond developers , testers and marketers? , do they make the whole picture…The answers to that is “no” . We need people who can act as “Pivot” & iterate on the product instead of the marketers , who in turn should worry about demand generation.

Steven states that “Microsoft needed a role that helped making changes further upstream. That way, there would be people who could facilitate changing the code, and minimise big fights”

What value product managers add?

Product managers help achieve intersection between customer feedback and how it impacts the codebase. The role demands ability to glean data and generate focus to mobilise the group towards most high value generating activity.

Steven reflects as “product leadership to be deeply personal, something that must scale within the product manager as the product scales”

What can make a product manager successful?

It is very necessary for a product manager to have deep understanding of the product & more so if the product is a software , then technical acumen becomes very important. In addition to this having ability to manage people and channelise their thought process is a very relevant soft skill that they need to possess.

Steven mentions in the blog that “knowledge helps facilitate a discussion. It makes one run through higher-level strategic thinking. It is important to understand the argument being made and then have a healthy way to address that.”

In Steven’s words “Skills in technology, user experience, and empathy (with internal team members and customers) are prerequisites that can be honed and trained. While building your expertise as a PM requires a mastery of all three areas, it’s important to remember that you’re never “done” building your skill set”

“There can be millions of debates that need to be addressed but sensing the meta-level information about the conversation – is the best entry point for problem solving.”

I think that is what makes a transaction based mind-set differentiate from a strategic outlook.

Qualms Of Product-Awareness

Product is a very generic term and changes its meaning depending on the context. As various stakeholders working to deliver an experience it is important to know how interactions impact your consumer space. This is more-over important for product managers operating in different context :- marketing versus technical product ownership.

Every interaction with consumer in the physical world or online is an opportunity to inform about our products and services. With channels through which we approach consumers becoming so pervasive , it becomes difficult to keep pace with the whole idea of creating product awareness. Although we invest time in creating prototypes , making MVP to test the market and then going full blow to complete the product only to get restricted by how to create awareness for the same!


flickr/creative commons

Product awareness has to be attributed to both external and internal stakeholders for us to impress upon the work that goes into building it. You would have often heard this phrase “Oh! I did not know this feature existed”  , reason being that we have not done enough to educate & make our stakeholders aware of the product & what it does.

Following are few pointers on how one could achieve a better product awareness index :-

  1. Information about the product:
    • Share your belief about the product and why you think it make an impact 
  2. Functionality & Quality
    • Talk about the applications that product can achieve for various customer segments
  3. Seek Consumer applications of your products
    • Consumers think of better applications of your products that allows you to create or disrupt the segment. These would generally be your evolved customer base , that understand the value you provide through the product.

Choice of MVP : Evaluate Your Options

Many a times MVP(Minimum Viable Product) and what definition it carries get clouded with lot of factors. To start with , let me refresh couple of aspects of what a MVP(Minimum Viable Product) may stand for:

“It is a core artifact in an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimise the total time spent on an iteration. The process is iterated until a desirable product/market fit is obtained, or until the product is deemed non-viable.”

Sometimes in doing above we tend to under-evaluate the cost of doing the MVP itself. Depending on what idea you are testing , there might be many things that might be involved in order to achieve the MVP state ( first iteration ) & although the software piece in itself might be easy or less time consuming , the offset of complexity does happen somewhere else. This leads to making choices of what the MVP should look like and more than often impacts the test results as well leading to premature conclusions about the MVP.

After observing and executing couple of MVP led designs , I have tried to put a simple way of looking at my MVP choices while working with the stakeholders. The spirit is to make stakeholders appreciate the choices they pick and how it can impact there test results.

In order to making evaluation of MVP choice more effective , I try to do following

  • Customer experience
  • Operational Complexity

The ideal state of an MVP would be to offer best customer experience with low operational complexity. But as everybody knows ideal state only nature provides and it is impossible for humans to achieve that ! Below graph is a representational state of making quick evaluation of your MVP proposal and seeing if the units within would face high level of operational complexity to achieve MVP state.

Some reading observations that you can get if you were to look at the graph are :

  • One of the biggest facts that this can help decipher is that if you are in a zone of delivering a good experience with high complexity , then it would be better advised to go for the best experience to improve outcome analysis as customCaptureer experience is determinant of the MVP state and its future outcomes.
  • The other outcome one can observe is that if high operational complexity does not bring about a notch above customer experience then rethinking the design is important
  • If you get best experience on low operational complexity then you might be operating very close to end state design and one should avoid iterating as it may lead you in over-engineering zone

Happy evaluation !

Bloated Duck Of Ideas…

While working through ideation process it so seems that river stream flows very fast and the rapids are furious when they come down on you , only to be gated by dams in form of viability and ability to implement them to achieve scale…

Now this is more operational view of the idea itself , when discussed but glaciers which generate those idea streams often think that they have been subjected to a speed gun and roadblocks are being created. Reality is that implementation don’t happen overnight and it is somewhat useful to pressure test a concept.

Idea generation process requires calibration ( and yes there are software for everything !!) but having mindset to do that is very important. Getting a better understanding of the outcome from idea and locking down larger versus smaller outcome scenarios is very helpful to build perspective for people who are part of it , who will get impacted and the originator itself.

This approach may help build a strategy of achieving what you want from the idea and prevent creation of a bloated ducks , who have swallowed more than they could digest 🙂

Also remember too much analysis will create paralysis.. so tread with caution…

The launch quandary

Often at times we have been faced with dilemma of launching products in market and when to bring it out of dock versus internal readiness.

One would state every company has metrics and decision KPI that can help managers effect such decisions but reality is it remains a quandary!! & ever so more in start-ups.

It is given that world would never be a perfect place and product launches are no exception. I would like to make one thing clear that I am not discussing development strategies but ability to define minimal viable product & letting the rubber hit the road. We often get stuck with following themes…

1. Does it contain all ideas of user flow envisioned
2. Have we written the code in best possible way
3. Did we incorporate all available internal feedback
4. Would customers accept this feature or not
5. Is every unit ready 100% to support the launch

It is important to frame a good test and learn strategy to counter these themes. We should try and adopt a calibrated way to solve launch quandary and most importantly take swift decisions. One important aspect to this problem statement is defining a minimal viable product.  What is that set of features which will allow you garner eyeballs and create nonexistent external feedback loops. Domain experts and technologists should come together and create that vision

It is given that customer behavior will always remain a black swan event and any amount of research will still elude you from reality. Some key things which can help get over this problem…
1. Define strict time lines and adhere to it
2. Create a minimal viable product set
3. Define scale of minimal viable product and set internal expectations
4. Strive for quickly setting external feedback loops