How to Keep Your Product From Falling Into a Slumber
Despite a promising vision and a positive start, tech product development can often falter along the way if denied a proper REST
For the tech-savvy reader, REST might sound like a discussion about RESTful APIs that are so critical today for any application to connect with the outside world. That’s not a bad guess. But there are more fundamental things that need to be in place for product development to succeed. Do note that success with product development is, by no means, a guarantee for success of the product. Getting the right pitch, offering the right value and tagging the right price point are some of the other factors that drive product success. We will park the wider discussion to fight another day.
For now, let’s restrict our focus to just getting it right with product development, which is a necessary condition for broader success with products. The “REST” needed by a product shape-up can be viewed as an acronym of the following enablers:
Resource
Half the job is done when you have the right people at the right position. Very often, this is easier said than done. Project discussions often start far and wide, aiming to get the best human and technological resources on board.
While there is no point in setting up a development unless it makes economic sense, one needs to be conscious it is not done at the cost of missing the bigger objective. How about using contract resources? In team A, resource X is only 50% utilized, and he can pitch in here? We don’t need to think about such project tools so early in the cycle?
Half of One and Half of One
Together add some fun … But
Can never make up for One
These are likely snippets of queries that often need deep thinking before a decision can be arrived at and cannot be based on just a single perspective. Clearly, there are no easy answers here.
Empowerment
While having the team in place is one part of the puzzle, empowering them toward key decisions, obviously within relevant compliance and capital controls, is also a critical element for success.
Approval mechanisms need to be decentralized. A product owner should be held fully responsible and accountable for his/her actions and also the way the product shapes up. A strong governance mechanism needs to be in place to ensure relevant stakeholders are on top of all developments.
Define the Sky
Govern the Why
How and What … Let it fly
Within relevant controls, means should be left to the individual’s/product team’s best judgement, while product sponsors and senior management should come after outcomes. The more skin the product owner has in the game, the more purposeful is the product progress and more meaningful the governance.
Space
A product development lifecycle — unlike a typical project run where the focus is more on steady-state execution — needs ample space: to experiment, to fail, to learn, to re-invent and to optimize. In fact, at a lower level of toleration, space is also a need for projects. But for a product to be successful and to stay sustainable, it needs enough free space to maneuver. The taller the product vision, the larger the need for deeper foundations of experiments and wider allays of optimizations.
Package Filled to the brim
Can have air drawn from its rim … but
A start in Vacuum makes the story grim
A product owner is often best placed and should decide on the right moments of corrective action or a change in direction of development approach. Within the broader product vision and defined controls, there needs to be enough room to fail a reasonable number of iterations — this is neither poor planning nor lack of capabilities.
Time
Almost an off-shoot of the space agenda is time. Any good product development takes time and effort. Rome was not built in a day, and no successful product can emerge instantly. Although there is no hard-and-fast rule around how long it should take, it is certain that years is not a bad yardstick here.
Invariably, no product development can happen under perfect test conditions, nor per a devised granular plan. Functional and technical maturity will take its time, and once the best or happy path is in, it does not immediately warrant an implementation or user-readiness. One needs to be aware that each of these phases is a critical milestone in the product development cycle, and passing one stage does not essentially warrant, especially immediately, closure across the board.
Winning a marathon
Calls for a steady move-on
Not a reality with Sprint shoes on
That’s four-in-four enablers. Simple enough to comprehend, logical enough to appreciate, but equally challenging enough to execute. Are you up for it?
Remember, if you take care of a product’s REST, the product will, in turn, take care of the rest.
