One of the fundamental roles of a Product Manager is to provide GO / NO GO decisions on certain features or Jira Cards. In a perfect world these are easy decisions to make with the full support of the business group. Usually saying GO is easy, NO GO is a lot tougher and can cause contention. When making these decisions, it’s important to view the situation holistically. Personally, every card I review goes through my “4 Ss”.
Scale
Scale is both a commercial and technical factor. On the commercial side, we need to be confident that the solution will work for at-least one customer (ideally the one that asked for this feature), x customers, a percentage of our user base, and a cross section of the various users we serve. Sometimes the feature proposed will be perfect for one user, but imperfect for most others. It may serve in our collective best interest to cause inconvenience the requesting customer for the greater good of others.
It is better to spend a bit of extra time ensuring the feature will work across multiple customers — this will inevitably save remedial work later to get the feature working for other users. The best way to accomplish this is by asking customers what their thoughts are. Of course, customers will be annoyed if we asked them on their opinion for every feature request, but we (Product and Customer Success) will intuitively know our customers while in role, allowing us to make proxy votes for them.
On the technical side, I like to take a pragmatic approach. If I were at Google serving a billion users, scale is a big contributor, but most of us work for organisations that will always cater to less than 100 million end customers (despite the lofty goals of our CEOs). This allows us to be more flexible when thinking of scale. In this context, it’s important we understand the theoretical limits of our overall business, and how long it will take to achieve it. If we’re a high growth start-up, it makes sense to architect for that feature to be used across many users, whereas if we’re a stable business with <10% YoY growth, we can be safe in designing technical solutions that serve the business as usual. In either scenario, developer discipline is key, and the use of good data structures and patterns will always be a good return on investment, no matter one customer or a million.
Sell-ability
I know sellability is not a word but bear with me here. For me, this is about how this feature will impact daily and long-term sales conversations. I don’t expect every Jira Card to become a shiny new sales weapon, but I do like to consider if this will make a material difference in the sales process. How many potential customers will benefit from this? Will this feature contribute to work that will unlock future sales opportunities. Every feature we implement that helps sales, contributes to our revenue, and it’s crucial we don’t forget that this is what ultimately drives our growth as a company (and more fun projects).
There’s two ways I measure sellability, first is the feedback factor — seriously understanding how many times sales comes back saying that the feature (or lack of it) is causing roadblocks to discussions. Many of these are quite obvious, such as the feature x, but there are also more subtle ones (such as UI). There are two caveats. One — the recency effect is human nature, and usually the most “important” feedback we get is from the most recent lost sale, which is unfairly weighted. Two — customers love asking for the kitchen sink when it comes to sales engagements, and sales of course has the unfortunate duty to still ask us of the possibility to implement. The best way to reach consensus is to participate in sales engagements — conferences, calls, on-sites, talk to customers, observe sales, and truly understand the various elements that come together to create a sale, or lose one.
The second measure is strategy, for example, we may have long term ambitions to have Forbes 50 companies as our customers, therefore every feature we build should be built to the standards and specifications required for us to comfortably offer it to a Forbes 50 business. This can go against current customer needs —our current customers in the suburbs have vastly different requirements to a company occupying prime New York real estate, and when this occurs, the approach I like to take is to side with strategy, and see how we can simplify the feature to also work for the current customer. This is an approach that does cause contention and is certainly just my approach to things, and does need a bit of a balance, but I do find that this helps our smaller customers understand the bigger picture and grow with the changes we make, ultimately benefitting them too, and improving our revenue from this source.
Support
Customer Support do impossible work, and the grinch in me constantly tries to put them out of a job (sorry team). Customer Support is the ambulance at the bottom of the cliff, and if we release a feature that needs them, we bear responsibility for pushing that customer off the cliff. Every feature we implement has some impact on a customer, and this will impact, increase, or reduce support tickets and requirements. A key success metric for feature releases for me is the reactive workload it causes for Customer Support. The best features are ones that are self-explanatory or explain once. Badly designed features or products tend to cause constant support issues and usually require remedial work later. This is distinct to proactive support — every industry is complex these days, and I’m a firm believer that the Customer Success Team proactively advise customers on new features and how best this can be used at their organisation. Our customers are intelligent, and if they are struggling to understand our new capabilities, we have a duty to ensure we build better and simpler.
The measurement of support is tricky because you don’t know the grief you cause until the product lands, and customers always somehow manage to find the one bug your testing team never found. However, working alongside the customer teams and listening to their alarm bells is a good start. I also like to trawl Freshdesk tickets on Friday afternoons and get a good sense of volume, sentiment, and customer patterns. For example, any change to software used in customer interactions (such as bag drop) always has more tickets than online changes, therefore we should be more cautious with changes to the former.
Finally, I see Customer Support and Customer Success as two distinct functions — one is reactive, and the latter is proactive. Proactive support is always better, and I believe that Product Managers, being the voice of the customer, should also spearhead conversations with customers alongside the Customer Team when new products are launched, when a feature that will delight specific customers are released, or when things go really wrong and we need to take responsibility for it with the customer directly.
Stickiness
Stickiness is probably the hardest factor to measure and is really about asking how this feature will keep the customer with the business. There’s a couple of things to remember here — we operate in a very competitive and standardised industry, most customers are indifferent to their solutions provider, and its our business to lose.
Delighting customers is probably my favourite part of the job and the one of the main reasons I’m a Product Manager. Customers really do appreciate it when you release cool products that will offer them a competitive advantage, or trickle down to delight their customers. Features that do this are often deprioritised in favour of critical requests, bugs, and infrastructure changes, but these features truly separate our company from our competitors, tell the customer we care about them, and makes the customer think twice before considering a move. These features don’t have to be resource intensive — sometimes minor updates to existing products can add tremendous value to the customer, and its important that we look at emerging technology, market, and customer trends to create product features or roadmaps that will address this.
Defending customers relates to ensuring our customers are receiving the same or better functionality that our competitors and the wider market offers. This is a tempting factor to ignore, because customers usually don’t ask for these features, and you (and maybe the customer too) don’t know they wanted it until the competitor pitches it in their sales deck. The best way to defend is market intelligence, and it’s important to constantly review the press releases and work being done by the far too many competitors we have in market. This is obviously important to protect our company’s market share, but is more important for our end customer — we need to defend them against other companies using better software to gain a competitive advantage our customers.
Finally, its important to remember that customers most customers don’t love or hate us, and as pessimistic as it sounds, we are just a cog in their wider operation. It is important that we don’t seek their attention constantly, and empower them to do what they want to do, with our solutions.
Putting it all Together
Ultimately, not all the factors will be equal when the decision needs to be made, and there will usually be a primary factor that drives our decision making. It is ok to make compromises, or even decisions that doesn’t sit well with you to get things over the line if it needs to be (e.g. when you know it will alleviate major pain right now, but cause a minor scale issues down the line). The best decisions are one where all four of these factors — Scale, Sell, Support, and Stickiness, are considered, and are all walking in cadence with each other.
Jay