Build it Right, then Sell it to Many (and Keep Repeating)

Building a software product is more difficult than doing projects or providing services. With projects, software is developed to meet the exact specifications of the client. Work begins only when the contract is signed.

The project scope can be defined accurately in consultation with the customer, and deployment happens in a controlled environment at client site, with known hardware and software. Support requirements are minimal.

Changes to specifications, or defects during development or after deployment, usually have limited financial impact. In T&M contracts, the vendor is paid regularly, based on efforts put in. Hence, changes and delays may in fact, bring in more revenue. Fixed price bids usually account for contingencies like delays. If specifications are changed, the vendor can ask to re-negotiate the price. Quality issues may cause loss of credibility, or at worse, project termination and denial of future contracts. 

A product, in contrast, will be shipped to thousands, or even millions of users. Specifications are based on the seller’s understanding of customer needs. Therefore, a deep knowledge of market and domain is required. Clients are not guaranteed, and marketing and sales functions are critical. Selling cycles are longer and more cumbersome.

Quality has to be outstanding, since the product will be used by a variety of users, and on a plethora of platforms and configurations, and not all of it can be anticipated in advance. As the diagram below shows, the cost of fixing a defect increases exponentially depending on when it is detected.

A post-release defect creates negative publicity and costs lot of money. A patch to fix the problem has to be developed and distributed quickly to the users. Even Microsoft has faced this problem repeatedly when hackers have exploited vulnerabilities in its operating systems. In another instance, a US-based personal finance company inadvertently exposed the private account details of several hundred individuals to other users. Such snafus can expose a product company
to expensive lawsuits.

A product business requires highly structured engineering and organizational discipline. Formal reviews are necessary at every stage (architecture, design, coding) to catch deviations from the requirements. Rigorous testing and quality assurance (test/QA) processes should be followed to detect defects before product  release. Test labs must replicate the myriad deployment environments that users  may have. This can become complicated for multi-platform products that support a variety of operating systems (Windows, Unix, Linux) and databases.

The installation procedure must be highly automated and work fl awlessly in all possible system configurations. New versions, patches, and future upgrades must install without any disruption to existing software and data at user sites. A strong support organization (on phone, email or onsite) has to be built.

Unlike projects, there is no end date for product engineering. They must  continue innovating and releasing new versions with more functionality and advanced features, to stay ahead of competition. Product organizations often have a signifi cant revenue component derived from services such as consulting, customization, integration and solutions. Unlike a pure services business, these are used to underpin and drive their product sales.

The ecosystem for products is more complex, consisting of engineering teams, product management, marketing, sales, consulting, professional services, distributors, system integrators, resellers and investors.

Reprinted from From Entrepreneurs to Leaders by permission of Tata McGraw-Hill Education Private Limited.

Let the world know about your software product


You’ve spent months and days and hours conceptualizing your product and then taking it to market. You’ve won the first few customers who are now stable and you’re thinking about what next…if you’ve achieved this, it’s time to show your product to the world.

The NASSCOM Product Conclave LaunchPAD is the place you should be to demonstrate your product and recount your journey from CONCEPT to REALITY. We’re inviting a select community to hear about you and your product. Won’t you come?

A day before NASSCOM Product Conclave kicks-off in Bangalore (November 6, 2012), we are pleased to host an exclusive interactive session with the media, blogger and analyst community where you have the opportunity to launch your new product and enjoy your moment in the spotlight. Last year we had some of the crème-de-la-crème of press attending the event and reporting it in the print and online media.

Who is eligible?
If you are an Indian software product company that has a software product in the market for at least six months and has at least one revenue generating (not beta!) customer, then you are eligible to participate. Apply for the Product LaunchPAD here before October 25, 2012.

What happens next?
NASSCOM shortlists eligible companies and informs them by October 30, 2012 Present your software product to the media at an exclusive event.

Publish a booklet containing information about your company and software product which will be circulated to the media and available online on the NASSCOM Product Conclave website. Opportunity to interact with a focused group of professionals and hear their feedback on your product.

Some of the folks who will help us short-list some great Products are:

Amit Somani, Arun Katiyar, Suresh Sambandam

Need further help?
If you need advice on how to structure your launch pitch or presentation, then please do let us know. Also we have many curated sessions at product conclave to help you take your software product initiatives even further. If you haven’t registered, then do so NOW!

See you at the NASSCOM Product Conclave – the place to connect with Indian Products Ecosystem.


The weight of expectation

How many times last month did you use Power Point? Most would have used it at least a couple of times. Power Point is one of those products that seem so natural and effortless to use. And when you think about it, Power Point acquires its muscle from its core ability to dumb down a variety of thinking processes. What were its creators — Dennis Austin and Thomas Rudkin – thinking when they were writing Power Point? Could they imagine that within 25 years their creation would be installed on over a billion computers worldwide?

Ironically, Power Point was designed for the Macintosh and was the first venture capital investment that Apple ever made. Forethought, the company which created it, was bought by Microsoft in 1987. With such a rich history and possibly the only company to have the two software behemoths in its DNA, we may well ask, “What have Dennis Austin and Thomas Rudkin done after Power Point?” Austin created some average-to-middling clip art (Screen Beans) and Rudkin worked for Microsoft in Silicon Valley, turning Power Point into a product with $100 million in sales. Why could Austin and Rudkin not create another great product?

That’s because creating software products is not like building a home or a work desk. The problems that software solves are not the same as those which apartments and office cubicles solve. Software solves newer problems (hopefully!) each time. That’s why there are more failures in creating software products than in making homes and offices. Every time a software engineer sits down to write code, the end goal is different – and often the end goal doesn’t stay the same through the lifecycle of the product’s development (surely you are familiar with scope creep and change requirements?).

It doesn’t matter that the profession has its own set of guidelines and best practices to follow. There are languages and project management techniques. There are tools and quality processes. Yet, practically any software project you come across has seen time and cost over runs, has versions lying on shelves that have been discarded, and has bugs that cannot be eliminated before release (these are passed off as “known issues”).

Why is it that creating software products is such a random process? Why can’t success be replicated even though the team has experience and ability? In other words, if there is a lesson in the creators of Power Point, it is this: building software products is not like constructing a home or a table with raw material that is pretty much standard. Software products have to be built from the ground upwards. From the framework to the data types and structures, from how the data will be
managed and manipulated to the protocols and networks that will come into play and finally how human beings will view it, store it, share it and deploy it. Creating software products is an intensely unpredictable process. The industry may try to provide examples of how great products were created, the role of engineering and innovation, of time and funding, of requirements and usability, market studies and prototypes and a whole list of other imponderables. None of them hold fully true when you get down to solving a new problem with fresh code.

The point is this: if you are trying to create a software product, the top most problem you have is not your skills or resources, but the expectations that industry has about you getting it right first time. You can’t will that expectation away. The trick is to not let it weigh you down – or even dictate the course you are charting for yourself.