Journey from Data to Insight – PART II
Given the scenario of data leading to insights, are you aware of how it could derail product development efforts over a continuous discovery process? Well! Here’s how you could balance it all.
Recap:
Over the previous part we covered the evolution of the whole journey of arriving at insight from the data on hand and the all-important 12-step methodical & organic process that’s so often the backbone of present-day data analysis and what essentially constitutes data science & inference.
PART II:
The Journey Continues…!
Talking of evolution over the parlance of building products (and largely software), remember how it all started with the conventional Waterfall model and then somewhere between debating about the cycle time and how teams are benched devoid work owing to heavy dependencies in the workflow, largely being inactive and non-participant to the entire life cycle of product development, we made that transition into Agile which seemed to advocate the overlapping of various teams’ workflows seamlessly so as to solve for the shortcomings of the previous model.
Thereon, we seem to have scaled up incrementally into offshoots of the Agile way of thinking leading to Scrum, Kanban, Pair Programming, TDD, XP et. al.
Looking at the way Agile preaches those best practices straight out the manifesto and the stage of the SDLC it fits into, it is inclined to product development or more commonly known as the BUILD stage, which is comfortably post-strategy.
So, what about the mistakes that come along pre-induced or get baked into the process of strategizing / strategic planning exercise? How would one go about identifying them and charting out action plans to tackle them?
There is no doubt that the advent of DevOps and the cyclical process of Continuous Integration, Continuous Deployment, Continuous Delivery has streamlined product development to a large extent.
But what about the strategy bit?
Intro to Continuous Discovery
A discussion with a strategist (a person who is meddling with strategy over one’s daily job) would so easily lead to covering the topic of “outcomes” as it obviously is the crux, the root of where it all starts from. Given a strategy starting off with questioning “why are we doing this?” at the very root, it would pretty obviously need an awful lot covered over the markets, perceptions of the users, emotions, motivations et. al. in general, which ought to end up in some semblance of a discovery so as to make the whole process successful, a fruitful outcome so to speak.
But here’s a question.
When does a team get cracked in over conducting any discovery?
Prior to the build alright (isn’t that obvious). But, most teams resort to discovery as a one-off activity taking acute pressure & forcing themselves to do the research, collect data, use it to prove or disprove hypotheses and get to what’d be perceived as a stable state of “DISCOVERY”.
But, given teams predominantly adhering to Agile practices and the cadence of releases (actually short ones) and how product development efforts get channelized into targeting those respective milestones periodically, does the whole concept of earmarking time slot for a discovery exclusively and only once prior to framing a strategy make any sense at all?
The visual here is a classic case depicting why many products fail owing to the adoption of features not hitting the minimum threshold levels, not taking off as expected, washing all the time, effort and dollars down the drain.
The turn of that very tide may have led to envisioning the concept of Continuous Discovery and one certainly has to quote the work of Teresa Torres and her book Continuous Discovery Habits (Discover Habits that Create Customer Value and Business Value).
Continuous discovery habits revolve around talking to the user community at a regular cadence and conducting interviews, spending time analyzing and reading between the lines of the verbatim so as to get a hang of their emotions, motivations helping teams gauge where the users and the markets stand now measuring for any sort of a drift and factoring all those problems in, enlisting them over a set of opportunities (OST - Opportunity Solution Tree) so as to reconsider and mold the strategy suitably, largely realigning the direction teams and organizations ought to take.
Some anti-patterns / warning signals that deserve a mention here:
when one is referring to the OST one is still effectively operating in the problem space and trying to frame a better strategy and is still MILES AWAY from the solution space
notice how “outcome” is listed at the root of the OST which ought to be defined prior to anything else as that’s what prompts alignment and you also notice how “solution” fits somewhere right at the bottom half of that OST which is NOT at all a coincidence
some may grasp some knowledge from the book and begin talking to customers at a regular cadence tricking themselves to believe that they are adhering to continuous discovery in practice, the reality is FAR FROM IT
some also debate about solutions directly and barely scratch the problem on the surface given how they go all out on a solutions-first mindset WITHOUT spending enough time exploring the problem space
Inculcating continuous discovery is tougher than anyone would ever imagine as it demands a total paradigm shift in mindset & across the hierarchy
So, how does one go about adhering to and practicing Continuous Discovery habits in their teams. Here are a few steps you ought to follow:
Few Real-world Problems
1. Continuous Discovery needs a mindset change
Problem:
Given the dynamic of an Agile team having to adapt to conducting discovery continuously, one can’t overlook the dependence on other entities like the outcomes that are earmarked for release over the current sprint for instance and after all a team can’t function effectively unless each and every member contributing in whatever capacity across the process chain adapts to it seamlessly.
Workaround:
Unless each and every team member gets to build an inherent maturity of the importance of adhering to timelines and match their discoveries against those outcomes, putting in an effort over apportioning them onto sprints, it could feel like an endless struggle leading to complexity that could spillover into chaos.
2. Balancing cadence of discovery & avoiding Tech Debt
Problem:
Supposing there’s a product team conducting discovery continuously and arbitrarily speaking it seems to have led to some (n) discoveries that have been earmarked for further exploration. Many sprints ahead let’s say they are currently working over the solutioning of the 5th opportunity discovered but the ongoing discovery that’s identified an opportunity is an exact negation of the 5th opportunity, which is to say that it doesn’t fit to be termed an opportunity anymore.
Here’s a tweet that describes just that:
https://twitter.com/BgpInv/status/1673927086246100992?s=20
Workaround:
People who have a stint in finance may remember the quaint saying that’s famous yet infamous at the same time which goes on the lines of “cut your losses short so to keep your profits running long”. This situation is no different here. When it could be seen as an effort wasted over piling up tech debt, although not really an attempt to surmount it, a reshuffle and realignment exercise could still save teams tons of dollars, effort & time, let alone the embarrassment of having to stomach building something that nobody wants. Bite the bullet and pull the plug!
Conclusion
No doubt! When going from data to insight ought to be done methodically, adhering to a stepwise process, it is equally important to put enough onus on the teams and the other environmental factors that happen to influence the whole process or methodologies of the product build so as to strike a fine balance between those outcomes, strategic initiatives and the individual team’s outputs.