What is wrong with product development today?
While having a discussion with the CTO of a company, while we were analyzing the numerous product changes we did in the past 4–6 months- he threw up a very interesting but disturbing question. He said, ” While each of the product features that we have launched have done phenomenally well- why is it that none of our topline numbers have moved?”
While we tried to scrape for answers which ranged from “Oh, these things take time to show result” to “Not everything can be linked to the top level metrics of transactions or revenue”. We knew deep within there’s something inherently wrong with the way products are being developed today in most of the product based companies in India.
I tried to reflect on the discussion and here are the things which in my opinion we are not doing correctly in the way product development is being done in most of the startups and product based companies. But before diving into the problems, let’s first understand what is a typical work flow of product development in most of these companies.
Requirement gathering: Things start with requirements- these come mostly from the “business” or senior execs or from the user (customers, merchants etc) directly. In most of the companies the product manager or product owner “prioritizes” these requests/requirements and comes up with a “roadmap”. Once the roadmap is in place, there’s typically a monthly or quarterly meeting with the business stakeholders and engineering team to finalize the scope of the next (or next couple of) sprints.
Story-writing and design: Once the scope has been finalized, the product manager/owner starts writing down the user-stories (chunk size requirements) and the design team picks up the “requirements” given to them as dictated by the “roadmap”.
Sprint Kickoff: There’s typically a sprint-kickoff meeting to “handover” the requirements (user-stories) to the engineering team (phew, finally!). In most cases, this is the first time the engineers get to know what they have to build (and why!?). And what more the engineers have to give a “t-shirt sizing” estimate of a problem they have seen/heard for the first time and have not even thought of how they are going to solve this.
Actual development: Finally the development begins and the engineering team realises for the first time what have they got into. Blame game begins with “designs not thought through for all use cases”, “requirements not clear”, “too many dependencies on other systems” etc.
QA/Testing: The lucky teams actually have a full sprint dedicated to QA or testing. The QA engineers again mostly have no idea of what the features are (forget why), and run after the product managers to understand the requirements and validate the test-cases they have written for those.
Deployment: Again some lucky teams have a staging/QA environment where pre-production codes can be tested and verified before putting on production/live. Finally the build is deployed on production.
As I explained the “typical” process in a product development lifecycle, some of the apparent problems became very clear and some other inherent/non-explicit problems emerged which I’m summarising below.
It is a WATERFALL model and not AGILE
The way a typical product lifecycle flows as explained above is waterfall, although we may fool ourselves by believing that we are following agile. It’s a typical “pass-the-ball” game where the person who is actually coding or testing or releasing wasn’t even part of the initial brainstorm session or in most cases doesn’t even agree or identify himself/herself with the product features.
Agile doesn’t mean being agile for the sake of it in the last design/coding phase. It has to be a mindset which must encompass all the steps mentioned above.
Engineers are not part of ideation
The engineering team is the best source of idea generation as they are the ones who know the “capabilities” of technology and understand the underlying architecture best. Most of the other folks- “business”, execs, designers, even engineers do not have that clarity. And the thing with users is what we all know- they don’t even know what they want.
By not having our best source of ideas- engineers early enough in the cycle, we are absolutely wasting them and restricting them to just writing codes. In my experience both at MakeMyTrip and nearbuy, the best ideas have come from my engineering counterparts. By the way when I say engineers, I don’t just mean the engineering lead/TM who will come in your brainstorming sessions, do some lip service and go back. I mean the actual software engineers who are going to write the code for you.
Have them as early as possible and you will not only get a lot of valuable ideas but also save a lot of time later in clarifying the doubts.
Focussed on output and not outcome
Sadly most of the tech teams are output focussed and not outcome focussed. I’ll explain with an example. Integrating a new payment gateway, putting the tracking code, redesigning the thank you page — are all outputs. And sadly most of the product managers and their tech teams have a huge list of such “features” which they are trying to check sprint by sprint.
An outcome focussed team will have the mandates such as “improving the payment success rate by 10 basis points”, “bringing the conversion through search to 8%”, etc. And to achieve those outcomes the tech team driven by the product manager will do whatever it takes to achieve that.
Giving the team objectives and not feature lists is the key to getting the team motivated to solve a problem. By doing this the team will generate a roadmap of its own and everyone will be equally committed for that.
It’s a race against time
I’ve always felt that we are racing against time and while I do understand that companies, especially startups have limited resources and more importantly, limited time to ship out things, what ends up happening is it becomes like an assembly line where requirements are getting dropped on one end and different workers are performing their bits and the products are getting shipped on the other end. What is required is a deeper understanding across the tech team of the problems they are trying to solve, their customers and their business. This can happen only when they are asked to solve problems and not deliver features in a given timeline.