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!

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!

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!

Financial Terminologies that a product manager can be familiar with


Whilst a lot of product managers are familiar with gathering requirements, working with management, user experience, development and testing teams, and other aspects of product development, not many of us are familiar with the financial aspects of running a business or development of a product.FinSt_$St

Some product managers are responsible for P&L of their products’ business, and I thought I’ll jot down some basic financial terminologies that we can be familiar with to understand financial statements.

Revenue

  • It is the total sales of a company after deductions for returned goods and discounts. It is calculated by simply multiplying quantity of sales by the number of units sold.
  • Revenue = Net units sold * selling price
  • AKA Top Line

COGS

  • It is the sum of all direct costs that go into the production of goods sold by a company — cost of raw materials and direct costs relating to manufacturing/production.
  • Indirect costs such as those for transportation and distribution are not part of COGS, but will be part of Operating Expenses.

Operating Expenses

  • Operating Expenses (OPEX) are expenses incurred by a company for running its business operations.
  • Expenses towards R&D, licenses, employee salaries, sales, marketing & advertisement, IT, utilities, and G&A can be considered OpEx.

Operating Income

  • It is the profit before taxes.
  • Operating Income = Revenue – COGS – OPEX – Depreciation
  • AKA Operating Profit

Net Profit

  • It is the net amount that’s realized as profits that companies can use for various purposes such as investment in same/new businesses and paying dividends.
  • Calculated as Net Profit = Operating Income – Taxes
  • AKA Bottom Line

Here’s a simple financial statement that’s prepared for a tea shop called ‘Chennai Tea Shop’. I have kept it simple and avoided comparative figures w.r.t. previous periods.

Chennai Tea Shop – Financial Statement for April 2014
Currency: Indian Rupees (INR)

ChennaiTeaStall

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When does software development end for a product?


Many a times we notice development teams getting annoyed and frustrated by feedback requests to improve certain features/experiences. annoy

Is their attitude acceptable?…

 

Let’s look at it objectively.

Software product development, particularly in the consumer industry (B2C space), is highly driven by user experience. There’s no way the Product Manager and UX designers could get it right unless it gets used by folks fitting the target persona attributes. Feedback from users is very important.

As Alan Cooper, author of ‘The Inmates are Running the Asylum’, put it:

The primary purpose of a persona is so that you won’t design for yourself, or for your boss, or that loud, annoying client.

Software development does not end with the ‘last development sprint’ of the release, but it continues until the product is deemed to be acceptable by the target users. Some developers get it but most don’t.personaacceptance

Most often than not it’s only after the last development sprint that product & user-experience acceptance phases begin with Dog Food and Beta tests. Any feedback that’s provided by these users will be evaluated by product management and queued up for incremental implementation.

 

Would love to hear your thoughts on how we (i.e. product management) could make software development think about the product from an end user’s perspective and take them on-board in the journey of building innovative-yet-user-centric products.

Product Management is NOT User Experience


There is an interesting article on this topic by Jeff Lash, and I wanted to share my opinion too.

Product Management and User Experience are different teams in companies — even though they work collaboratively tYou are herehe organization structures are completely different. Both functions are not the same — there may be some overlap but they are not the same.

Whilst User Experience is critical to any product, product success is beyond UX design. Some companies are completely oblivious to the difference and they treat both teams in a similar fashion.

UX teams have managers. UX teams have directors. UX teams have ownership too. If the UX team comes up with a design which is to the best of their ability, and if that gets poor reviews (by management, beta testers, or end users), then why should the Product Manager be held responsible for it?…