Need 9 months to get baby out

One of the pressures and challenges of working on products is to get it out soon – the release. But I often recollect one of the leaders that I have worked with saying “need 9 months to get baby out”.

9monthBaby1

What’s the right time for a product release – Some Considerations?

Build for market, not a customer

9monthbaby2

Remember products are not built for one customer, its built for several of them, for a market. I highlight this as especially in India, we have abundant  services companies and people with great experience driving innovations and solutions for one customer, and often the release time for such delivery can be done in a shorter duration as we are working towards a specific requirement set.  Its different to build it for a market or many customers in mind.

Enough research time to iterate

9monthbaby3

The other key aspect of building a product is to spend good time on researching the market, understanding user problems and figuring out what to build, before start building it. In certain cases it could also be some initial prototypes to get the thinking process going. Often this time is ignored when building products.

9 moms cannot make 9 babies in 1 month

9monthbaby4

By getting more people assigned is not the solution to get the products out faster, actually it could be counter productive as there may not be enough components that can be built parallel and also could result in confusion on co-ordination.

It’s not just about development

Many software products fail primarily because they put all the time and effort only in engineering and developing the product and do not plan for an effective early adoption and go to market (including pricing) launch time planning. They consider this as lesser important task and often consider this as a post product release activity. But the market readiness and go to market should be planned well ahead, and enough time to be allocated to early adoption and launch cycle.  The other aspect that gets ignored many a times is user empathy and design for user interaction and interface.

Focus on quality, differentiators

9monthbabay5

Bugs are fine in software, can be fixed is the typical attitude in software industry. But depending on the mission critical nature of the products, quality is going to be key criteria. Thorough testing and quality is an important part and while dates can be compromised, quality should not be compromised as the word spreads if its buggy. Get it out with good quality.

9monthbaby6

Many products compromise on features and differentiators, to deliver a product in time. This again can be dangerous in the current extremely competitive world.

So usually the right time of the release should have key focus on quality and differentiators.

Alpha, Beta….

We come across examples of products that get released to market without alpha, beta cycles – without being taken to first few customers or users to try out. This can be dangerous, inspite of the time pressures or the brutal confidence that you may have about your products and self testing, there should be time allocated for alpha and beta trials.

Rapid release cycles

9monthbaby7

The other side consideration here is that while products have to be planned, it can’t take too long as well. Many of the established players get into this syndrome where they spend too much time planning and laying it out but by the time the product comes out, the market is lost or captured by some one else. This is where agile methodology comes in handy. Products should be planned in such a way that there is minimum viable scope covered coming in from the research and there is agility built into cover a rapid release cycle post the first launch, where more enhancements can be planned, based on customer adoption.

So if you started reading the blog hoping to get the answer on the right time for a product release, sorry for disappointing you. But from my experience where I have been involved with enterprise software products that were built in 3 months, 6 months, 1.5 years, 3 years etc. , some of the above points were the learnings for the success or failure of the product. Plan time for the ideation/research, design, development, thorough testing, beta and GTM launch planning before getting your baby out…

Share your experience or other considerations that I may have missed here…

Why a degree of chaos is better than order

I can bet you are familiar with this one, but not its consequences, in product development: you’ve seen project managers in product development teams express frustration at not being able to keep the development on track, on time and on budget. I had earlier written about the kind of expectations people have of product development and its perils – but this problem of project management is worse. In response to delays, project managers begin to get even more hyper. They start asking for more detailed plans, better definitions of deliverables, tighter schedules, better time and resource utilization and more frequent reviews (ouch!). That’s natural. That’s what project managers are born to do. Except, in the product development context, this approach is just not applicable. It’s a great approach in manufacturing and service environments where assets are under performing and people need to tighten their process management. But in product development, this can all but kill the development.

Product development and shop floors are very different – to start with code being developed can be in several places at the same time, in the hands of different people, undergoing several changes (and becoming altogether new products!). This just can’t happen in a manufacturing scenario. A copper pipe being manufactured can only be at one place on the shop floor. A car being manufactured can only be at one point on the assembly belt.

The difference is crucial. And well worth appreciating. Product development managers can’t afford to have their teams ticking at 100% utilization. Not even at 90%. It can cause untold harm. In development, busy does not necessarily translate into productive. Reason? Nothing is predictable in product development (again, I hark back to my older post on the topic at https://pn.ispirt.in/the-weight-of-expectation/). Development thrives in chaos. No one is certain how long a task in development will require – or should take. Unlike in manufacturing and services, where there are well-set benchmarks for most processes, in development there are practically none. Teams should be given leeway to make unpredictable changes, and start from scratch. And starting from scratch does mean low people and process utilization.

Bringing order to development is futile. Okay, I’ll take that back and rephrase it a bit: Bringing order to development is not recommended. This is because the process of development has large variances and reducing those variances can take up considerable resources, adding to project costs. In a world of shrinking resources, that’s a trade-off few will opt for. Or am I in a minority in thinking this?