4 *CRUCIAL* steps to land great INNOVATIONS
Here are 4 simple steps you ought to put yourself / your teams through towards improving chances of landing great innovations... And are you doing this enough?
Although there’s a lot of conjecture about where & when this incident happened, without staking any sort of a claim to mere statistical / historical perspective let’s dive right into the scenario…
There was a panel of members who were conducting this interview for a senior ranking officer of state affairs and in walks a candidate. He walks up to the panel and meets each one of them from left to right with a firm handshake, eye contact and a confident smile whilst maintaining the poise of a gentleman.
He’s sitting there confident enough waiting for any of the panel members to pop the first question whilst they are skimming through the credentials with their heads down.
And then all of a sudden one of the members at the far end reaches out to the switch and flicks it on turning the pedestal fan on and blazing with full speed. As a consequence of that, all the papers lying aimlessly on the panelists’ desks begin to fly helter-skelter.
One of the panelists asks the candidate to pick up all those papers and organize it.
The candidate lifts himself up from the chair and taps the desk-bell hard continually. And within seconds the peon comes running in. The candidate turns to the peon and politely asks him to pick up all the papers and place them back on the desk. The peon gets to work immediately when the candidate walks back and takes his seat maintaining a sense of calm & composure.
Most managerial jobs aren’t about obeying instructions on a blindfold as they would often require one to step-up and be assertive about the decisions they make whilst approaching everything with a sense of calmness logically backing it up with hardcore facts or data & insights thereof.
CASE STUDY: Fintech
Consider a scenario where a PM at a Fintech org is tasked with building a feature that prompts the users regarding their recent payments & populates them right there on the screen making it ready to go in one click.
Now, the worst thing a PM can do is to go ahead, swallow that input hook line & sinker getting onto building the feature.
Why, you ask?
The feature may await its impending doom post release when teams get to realize how no user clicked on that CTA pertaining to the “frequent payment” feature en-route to initiating one of those payments.
Am sure you’d agree that’s a total waste of effort, time & capital.
What may have been a better approach for the PM?
Starting off with these perhaps…
Let’s take up these questions one by one & see how we can reach a state of clarity.
1) Purpose
Understanding the purpose would be the first step in reaching anywhere close to the clarity we’d need over the feature to be built. And, that may include the exploration of the background, the pain points, the problem coverage as in a subset of the sample space that may resonate thoroughly with the idea. Here’s a few questions you ought to be asking:
1.1) Why do we have to build this?
Let’s supposing the due diligence in terms of research, discovery has been completed and it points to this.
Many users have made it abundantly clear that they would have saved a lot of time if the entries on the form were populated reducing their burden of having to key in the same information repeatedly as the payment is recurring. So, that establishes the pain point is established for sure here & the need is now clearer.
1.2) What’s the frequency / cadence?
Following that up with another crucial question which pertains to the frequency of the payment could be critical information prior to jumping into the solution design.
Some payments could recur on an annual or a weekly cadence when most payments could be recurring monthly. Knowing the cadence could also hint at the impact the problem carries right now and could lead to a fair estimate of the sample space.
2) Impact
“Feature factory” is a phrase that’s common in the product world for orgs & teams who focus entirely on building features putting them out on a regular cadence without even realizing whether or not teams & resources are being utilized optimally to create value to the users which is the only way one can generate the required impact one is after.
2.1) What’s the size of the sample space resonating with the problem? How big is it right now?
When most PMs could jump into an assumption of the problem coverage, as in the subset of the sample space that identifies with the problem using some basic math / extrapolation, the reality could be entirely different.
It isn’t necessary that a problem seemingly massive would resonate with a large section of the users. That’s certainly not a given. Historical figures & STATS suggest that most users denied any cognizance of a problem that seemed massive to the product team. A few ways one could arrive at the estimation of that sample space is:
Surveys
Micro-surveys
Trapdoors
Continuous discovery methods
2.2) What are the chances that the sample space would swell in due course?
Yes, one has an extrapolation of the numbers proving to be validation enough for the presence of the pain point. When that is good, there ought to be enough thought allotted to understanding whether there is a chance for those numbers to increase thereof. And one could get there by studying these:
target personae & its deviation from the ICP (Ideal Customer Profile)
GTM & how it’d affect the inclusion of the sample space
competitors & features available in the ecosystem today
current needs as pitted against future trends
One special mention for studying market trends is how it could dictate the entire course of the strategy. If one is operating in disruptive tech it’d be better to study the market trends very closely. There could nothing worse for a PM than building for a market that they thought was there & now stands obliterated given how markets have pivoted onto something entirely new.
“These above-mentioned sections could prove a handful & help validate assumptions, get to a clear definition of the problem, the size of the pie that resonates with the problem alongside other nuanced & useful info about the problem itself”
3) Metrics
Its commonly said that without progress we’d all be dead as PMs and that’s so true. Tying each of those features to a strategy so as to help achieve a specific goal ought to be one of the innate strengths of PMs. Also, without measuring by how much the needle on a specific parameter moved, one can never be sure of whether or not they are in the right direction, let alone achieving those goals.
3.1) How can we be absolutely sure about making progress?
The clarity arrived at over the previous section ought to be a mandatory exercise prior to every feature being envisioned (NOT BUILT) and the best time to get this done is parallel to strategy formulation.
There are highly specific metrics (or a bunch of them) that could be tracked individually (or collectively) as they can help quantify the progress successfully making it more tangible an entity to pin on post deploying a strategy. To arrive at those one could ask:
What’s our goal in question here?
How do we define success for the new feature given the goal?
Measuring it at what cadence makes perfect sense?
3.2) Exactly what metrics do we measure?
The definition of success could be a precursor to pinning down on specific metrics. And the reason there could be a bit of confusion over this contingent for especially new PMs / aspirants is how that definition itself could vary.
If success over a feature release points to building engagement that could be entirely different from improving revenues. And when the reliance over vanity metrics is a given, PMs ought to be able to derive a more nuanced set of metrics. And one could get there by asking questions like:
Given our goal (x) what exactly would indicate that we have hit the goal?
How do we employ a combination of parameters to devise a metric that stands to quantify the success we’re after?
4) Solution Design
Now, this is the place for the “why nots” to surface. If you aren’t questioning the status quo as a PM here, you may find yourself lagging behind in the race.
And the one thing that could be a measure of the innovation is perhaps a differentiation strategy that could answer the questions:
What can I do to make my product / feature unique?
How do I make it hard to copy?
What’s the best (design) approach to this problem?
Rolling back to our Fintech case study from earlier, this could lead to a structured approach towards an innovative solution. We could start by asking:
Does it make any sense to populate fields via an auto-fill?
Or do we build a feature that could allow users to define a cadence for a transaction in case they want to repeat it (asking them to input the cadence)?
WHY NOT pop up the recurring transaction facilitating the user to choose exactly which one they want to repeat (assuming there are multiple such transactions that qualify)?
Or WHY NOT build a provision to set a “Standing Instruction” removing any chance of error, fool-proofing it entirely & making it totally automated?
Post validating the effectiveness of that solution choice (assuming the one chosen in the Standing Instruction), it could be as simple as incorporating a tick ✅ towards scheduling the transaction automatically with real-time reporting of account balances post completion.
One could also choose to test these out with a handful of their sample space to gather feedback regarding the effectiveness of solution coverage in terms of eliminating the problem & of course the UX part of it as well.
In conclusion:
Asking “why” towards what’s prescribed & followed as customary practice / process & asking “why not” towards enabling / enforcing innovation is obviously two best habits one could inculcate as a product person.
And FYI, remembering the structure of questions here and how they help unveil the purpose, they could be apt for use even when you face interviews as well.