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!

Advertisements

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?…