Synopsis: The Art of Product Management


I was fortunate enough to bump into a presentation from Sachin Rekhi (@sachinrekhi) called The Art of Product Management.

VSDE

It was an excellent read. Here’s a synopsis from it, for my product management friends.

Product managers drive the Vision, Strategy, Design, and Execution of their product.

Vision – articulates how the world will be a better place when you succeed

  • A compelling vision articulates how the world will be a better place when you succeed
  • Get excited about being at least one step forward, one step closer to it
  • Best format: write a customer oriented vision narrative. Jeff Bezos expects a 6-page narrative!!
  • A vision is valuable only if it inspires the entire team
  • Communicate the vision — the power of repetition — just as it takes 7 impressions to garner a response to a marketing message, you need to constantly repeat your vision. Ask your team about what they’re doing and gauge if they are communicating along the lines of the vision, using words & phrases from the vision.

Strategy – iterate & refine until you find product-market fit and you are dominant in your market

  • It’s about how are you going to win
  • A vision should be stable, but your strategy needs to be iterated on and refined until you find product-market fit and until you are dominant in your target markets. Again refine to expand to new markets and find product-market fit there.
  • A better fit leads to a more appealing product for the target market
  • A faster fit means the product will enjoy maximum differentiation for a longer period of time
  • Best format: Product-Market Fit Hypotheses
    1. Target Audience — bulls eye of your very best potential customers
    2. Problem You’re Solving — it’s important to articulate the problem independent of the solution, get to the root of the problem than scratching the symptoms, fall in love with the problem you’re solving for your customers and not with the solution
    3. Value Propositions — not the feature list, but the promise to your customers on the value you will deliver for them
    4. Strategic Differentiation — why is your solution 10x better than the leading alternatives
    5. Competition — how will your solution win against direct competitors and indirect alternatives
    6. Acquisition Strategy — how will you find & attract your potential customers in a cost-effective way
    7. Monetization Strategy — what are your primary and secondary ways to make money, is there strong willingness to pay
    8. KPIs — what are the right metrics for you to know if you are headed in the right direction. Spend time frequently (almost everyday) reviewing critical metrics & dashboards.
  • Minimize your dimensions of innovation. Don’t innovate on all aforementioned dimensions, instead innovate on few and use best practices for the rest.

Design – keep it simple and bring emotional intelligence

  • Work hard and iterate to keep it simple
  • A compelling design delivers a useful, usable, and delightful experience to your customers, by bringing emotional intelligence to your design
  • Develop personas – a persona typically describes the goals, pain points, behaviors, and psychology associated with members of a particular segment. Give them a name, a profile image, and sometimes associate a background history with them. A team usually develops one or more personas to represent the core audience of users they are optimizing their product/experience.
  • Increase Exposure Hours — it is the amount of time your team spends with observing customers
  • Delight through attention to detail and by making people feel accomplished
  • Measure delight through NPS

Execution – it’s not about project management it’s doing whatever it takes to win

  • Be relentless, it determines whether you’ll make your vision a reality
  • You must spend about 60% of your time in execution, else it will go wrong
  • Execution is not about project management, but doing whatever it takes to win
  • Ensure you’re pointing the team in the right direction. Reward engineering velocity.
  • Execution Loop: Define >> Validate >> Iterate
  • #1 Goal: Increase execution loop velocity
  • Establish yourself as the curator, not the creator of great ideas. Everyone contributes great ideas.
  • First nail it, then scale it — first build software quickly (no elegance required in architecture, etc.), validate it, and then scale it with elegant architecture.
  • Invest in retrospectives

Hope you found this blog post useful. Thanks to Sachin Rekhi @sachinrekhi. Cheers!

 

 

 

 

Advertisements

3 qualities of leadership folks I most enjoy working with


The leadership team is ultimately responsible for the success of their companies.

They have teams of their own — product, marketing, sales, engineering, etc.

Being product managers sitting in offshore offices across India, as we are not part of the leadership team in the headquarters (due to timezone differences, onsite office vs. offshore office mindset, etc.), it is essential the leadership team attempts to take the product managers along with them in their journey of steering the company.

Essentially, there are some qualities we expect in our leaders and below are the top 3 qualities of leadership folks I most enjoy working with:

Three fingers

1. Groom team members into future leaders
2. Share business, company, and priority updates instantly
3. Give credit to team for successes

Would love to hear what others think!

Product Company Org Structure. A Wild Aspiration.


 

Gopal Shenoy,  product management leader and a famous blogger, made a blog post on how a product manager is not the CEO of their product, and one of the main points of contention was that, unlike a CEO, a product manager has no authority, and hence product managers are encouraged to work in the lines of influencing cross functional teams and position themselves as the Chief Influencing Officers (CIO) of their product.

Whilst I agree 100% with Gopal Shenoy’s view of product managers as CIOs, I’d like to make a proposal on how to achieve the CEO tag which will make us better product managers with higher levels of responsibilities.

Definition of a Product Manager

Here’s a good definition of a ‘product manager’ that I bumped into recently.

Product Manager - good definition

Source: Anonymous

One of the key aspects in this definition is the product manager’s responsibility and ownership over the product deliverable — we all agree we have that responsibility.

The Reality

Based on my experience, I feel the ‘responsibility & ownership over the product deliverable‘ is extremely challenging to exercise with the org structure of today’s tech companies. Engineering management has too much control over their engineers, especially around working on a defect vs. a subtle refinement based on product manager or dog-food feedback — this is because they think they own the delivery of the software features. Just too much authority based thinking. Engineering’s focus is more towards securing their position, name, etc. rather than shipping a great product that has market/customer acceptance. The hands-on engineers tend to listen to their bosses more than the product manager because they have to look good to their bosses around performance assessments.

No matter how much there is excitement about flat/matrix organizational structure, layers get developed within engineering teams over a period of time for reasons such as career advancement, retention strategy, etc.

Proposed Org Structure

As an aspiration, I’d like to propose an org structure for product companies, with the intention of ensuring fairness to product managers in fulfilling their responsibilities.

Product Manager

  • Reports into VP/Head of Product Management
  • One or more projects assigned to each product manager
  • Engineers assigned to the project will officially report into the product manager
  • Works with the assigned designer, architect, and engineers in delivering increased customer value, eventually leading to exceptional product-market fit
  • At the end of the project, or on a periodic basis (e.g. quarterly), provides feedback to head of engineering on the performance of engineers
  • Team reporting into product manager for each project

    • Designer
    • Architect
    • Developers
    • Testers
    • Scrum Master
    • Analyst

Engineer

  • Reports into assigned project’s product manager
  • Reports into Director/VP/Head of Engineering on a dotted line
  • Collaborates more with product-manager vs. his/her boss
  • Works with Architects to groom their technical skills
  • Brings innovative problem solving ideas to the table

Director/VP/Head of Engineering

  • Works with VP/Head of Product Management in understanding project priorities
  • Align with rest of the leadership on resource assignments across projects
  • Use feedback from product managers to assess performance and rewards for engineers

Benefits

  • True matrix org, with no middle management or authoritative layers
  • Focused on the products’ success vs. team glory
  • Engineers will focus their efforts in building great products & experiences, and not in pleasing their bosses
  • Engineers need not be in a dilemma about who to listen to — their line manager or product manager

Cheers!

When Product Managers Get Trapped…


How many of us product managers have been in this situation — trapped in an organization, an organization that does not understand the essence of product management.

An organization where:Trap

  • Product managers are responsible for clerical tasks and book keeping
  • Product managers are required to project manage
  • Product managers are made the scapegoats for engineering failures
  • Product managers are required to double up as functional managers to cover up for poor engineering managers

A few of us would certainly have some experiences to share.

If at all, we end up in such a trap, here are some tips (read as arsenal!) that could be used in times of need, so that organizations/leadership-folks understand the need for product management for product and overall business success.

  1. Data – make use of data and unearth insights about product usage patterns
    • This will make the leadership team feel the need to improve product design
  2. Competitive Landscape – research into your competitors’ products and identify gaps in your offering
    • This will surprise the leadership team
  3. Market Trends – research your target market segment and identify unmet needs
    • This will enable trust with the leadership team
  4. Feature Prioritization — effectively prioritize your features using a good tool
    • This will delight the leadership team
  5. Portfolio Analysis – do an analysis of your company’s product portfolio and let leadership know about products that need investment vs. the ones that need to be killed
    • This will give sleepless nights to the leadership team, for good:-)
  6. Product-Market Fit – constantly pursue the leadership team to understand achieving product-market fit sooner than later, because faster product-market fit will ensure the product will enjoy maximum differentiation for a longer period of time

Hope you liked the post. Would love to hear your insights too!

Feature Prioritization *New*


Back in 2011, I made this blog post on prioritization of product features, and the prioritization template looked like this.

Over the years, I have been updating the format and refining it to ensure it articulates the objective prioritization and shepherds the product towards product-market fit — the latest is here.

In general, features will have to be categorized into three backlogs. The backlogs have been named by lifting NBA terminology for self explanation.

  • Offensive Play — features that aid revenue generation and acquire new customers
  • Defensive Play — features that aid in delighting and retaining existing customers
  • Time out — features that aid cost cutting such as those that reduce product returns, reduce customer service costs, improve operational efficiency, tech deprioritizationbt, etc.

Product Managers will have to ensure appropriate ‘plays’ are adopted depending on business needs, including a mix of features from more than one backlog in a release, for creating customer value, generating competitive advantage, and delivering profitability.

Few takeaways:

  • Strike the right balance between offensive and defensive plays
  • Features that can be implemented in a shorter time are *not* always the ‘right thing’ to do
  • Always look at relative priority and the objective impact a feature will have on customer value, ROI, and overall purpose

Would love to hear what’s on your mind!

Is MVP the right approach for launching consumer products?


I’ve come across many people, particularly UX designers:-), growling when they hear the word ‘MVP’ (acronym for Minimum Viable Product) — it’s because some of their favorite features/designs get missed out.

Most people think MVP is just a bunch of features that are being planned for the first release of a product/solution or just another scoping exercise. Some of the traditional definitions too confirm that thinking.

  • MVP is a set of minimum features, a minimum feature set
  • MVP is a feature set that allows the solution to be deployed, and no more
  • MVP is a set of features that ‘can be’ delivered by the expected date
  • MVP is a set of top features that users asked
  • And so on…

On the contrary, I believe MVP needs to be conceived with a 360 degree perspective on how the initial offering will benefit customers and stakeholders. And of course, within budget and schedule constraints.

To summarize, an MVP needs to:

  • epitomize core value proposition with the right mix of features/experiences
  • justify ROI vs. risk
  • help determine user acceptability of the offering
  • help identify demand for specific new features
  • promise great new things ahead

MVP

Would love to hear other insights and feedback!

Motivating Development Teams


I bumped into this article almost a year ago, and it’s only now I’m finding time to blog on it.

http://www.mironov.com/motivating/

Great thoughts there. Following are some of the things I’ve practiced and they work well.

  • Inform the team about the product demonstrations you conducted and how much the audience appreciated their work
  • At every opportunity, give them the feeling that they are great developers, specifically in sprint planning and product demonstration sessions
  • Reiterate the impact some of the features will have on customer experience, product ratings, and on the overall business
  • When junior developers think in similar lines to that of their seniors, point it out to them and get them excited about it
  • When giving suggestions for technical design or product scalability, always end with the note that they can come up with something better
  • Never make them feel bad or low about some obvious questions they may have
  • Take them for lunch or dinner at opportune times
  • Crack jokes at opportune times (even recycled jokes work!)

Do share what you do to keep your development teams motivated!