Apr 13, 2006
The First Annual A-SPIN Software Debate: "Why Products Fail"
- Jack Long, Cofounder, Lone Star Overnight
- Stephanie Weber, Director of Product Management, BearingPoint
- Aaron Jackson, Senior Development Manager, Zone Trading
Our panelists represent three distinct perspectives on the product development cycle and will explore in detail two product development scenarios, one for a small and one for a large business.
Why do Products Fail? (two "case studies")
DataDoctorIdea Person offers IT consulting services to doctors. In talking to clients, Idea Person recognizes a need for doctors to have access to a unified set of patient records. He envisions DataDoctor, a HIPAA-compliant super portal where patients can store their medical records in one place and authorize access to any doctor.
After some initial research and consultation with venture capitalists, Idea Person scraps the idea of a patient-driven model. The scaled-down system will allow a smaller set of doctors in a particular value chain to exchange records. For instance, MDs can send referrals to podiatrists, who procure digital images from labs, refer the patient to various treatment specialists, and then share results back to the MDs.
Idea Person pulls together seed capital to produce a barebones beta system. Idea Person finds Developer Guy, who promises to build the system cheaply and quickly. They concur on the urgent need to control scope. Idea Person will serve as the customer liaison and provide requirements to the developers, who will use a modified Agile methodology to achieve maximum flexibility.
Idea Person visits the development lab 2-3 times a week. The developers grill him on requirements, starting with high-level requirements and then drilling down. Idea Person soon finds himself spending more time liaising with doctors and their staff. He decides to invite Developer Guy and two of the senior developers to accompany him on visits so they can see the customer environment first-hand. Mid-way through the second internal iteration, Developer Guy concludes that the original slicing of features is unrealistic because of data dependencies. The team reacts fluidly and adjusts the project, but the release schedule is now three weeks behind. The team scrambles to catch up.
As the requirements take shape, Idea Person and Developer Guy revisit the strategic IT needs of the business. Doctors are risk-averse people. And without economies of scale, the business will struggle to grow the customer base. A robust architecture will be required that is scalable, extensible, dependable, and easy to integrate with a variety of systems. Yet these needs are offset by Idea Person's financial constraints. After due consideration, the primary goal remains a product that Idea Person can sell quickly.
The team's first internal release reveals many defects. Idea Person is able to mask these in product demos while the team scrambles to fix them. Doctors are impressed. They like the intuitive interface. Idea Person closes a beta system agreement. Venture Capitalists step up their investment. Idea Person promotes Developer Guy to CTO and doubles the size of the IT team. He hires Product Guru as product manager. New orders pour in.
But so do complaints as beta testing gets underway. Down-time is considerable. Users complain of quirky errors, of files getting stuck, and of waiting up to a minute for web pages to load. On her third day, Product Guru endures a scolding from a doctor who can't log in. The new developers are baffled by the poorly-documented architecture and their changes cause regression defects. Idea Person and Developer Guy are in complete agreement that the system must be overhauled. But this proves easier said than done. There is huge pressure to make the product more customizable. Even with HIPAA standards taking hold within the industry, integration of DataDoctor with diverse backend systems proves a headache.
The executive team decides to push through a hybrid release that refactors some of the underlying architectural issues while at the same time addressing key functional concerns. This release proves over-ambitious and runs into many problems. Some of the original developers lack the necessary refactoring skills, but Developer Guy fears disrupting the team. The old developers don't trust the new developers, nor do they trust Product Guru, who they feel has less direct experience. The developers want to invite doctors and their staff to guide requirements directly, but Product Guru rejects this idea as unrealistic given conflicting customer needs and time constraints.
As both the second and third product release dates slip and customers
begin to bail, the venture capital team steps in and assigns an aggressive
CEO to turn the situation around.
Project Green Light
Big Corp builds software systems for UAV drones. The company works with several drone-manufacturing companies located around the US and Europe. Its software development team uses a RUP methodology, with business requirements provided by a team of product managers.
Despite the company's bureaucratic name, Big Corp's vice president for marketing, Idea Person, likes to think out of the box. He believes the company can recycle its experience in UAV software to develop proactive traffic light systems. Idea Person's neighbor works for the River City Traffic Department and they have spent many long nights discussing how to improve traffic flows during off-peak hours. A system of traffic lights that can see cars waiting at empty intersections and allow them to pass through more quickly could help to reduce pollution, and even reduce rush-hour traffic by speeding up the throughput of cars in the period before roads reach saturation. The market is vast and, despite the presence of potential competitors, largely untapped.
Idea Person hires Product Guru to oversee the initiative, codenamed “Green Light.” Work begins on the “fast-light” feature, which requires software installed at each individual traffic light to be integrated with cameras. The reuse of UAV software components means that at a later time, the individual traffic lights can be connected using wireless technology to a central system. The first release is planned for March.
As the project unfolds, Idea Person discovers that a major US city, Metropolis, has an RFP out for a related feature that allows drivers to calculate the optimum time and route to their destination using an internet portal. Idea Person instructs Product Guru to draft a proposal and add this “route optimizer” feature to the first Green Light release. With buy-in from River City officials, the release deadline is pushed out to June.
Product Guru discovers that there are many differences between UAV processes and traffic light processes. Adjusting object-identification algorithms to a city street environment prove complex. She encounters resistance from city transportation officials who feel the Green Light project clashes with various county, city and state traffic safety regulations. The rewriting of requirements to accommodate wireless connectivity takes more time than planned. Traffic light manufacturers view Big Corp as a competitor. River City planners soon learn that their “fast light” prototype will not be ready until August.
However, they see the advantages of the wireless technology and conclude that Green Light is the perfect vehicle to support a well-publicized City Metro project that will allow consumers to determine the exact time city buses arrive at a bus stop. Highly dependent on River City's good will and unwilling to resist this request, Idea Person instructs Product Guru to add this functionality to the release, now planned for December. Product Guru and Developer Guy warn that this will not be feasible. However, Idea Person has managed to sell the emerging product package to Sunny City, California. The Californians want to see the “bus stop estimator” by January so they can compare it with another company's prototype. Idea Person wins agreement from River City to defer the original “fast-light” feature and focus exclusively on the “bus stop estimator” and “route optimizer” features. He instructs Developer Guy to triple resources on the project and do whatever it takes to get the project out the door by January.
As January looms, Developer Guy is forced to report that the project
can be ready no earlier than April. He blames Product Guru, who has
struggled to provide a stable and complete set of requirements. The
“route optimizer” feature has proven particularly difficult.
Idea Guy controls his anger. He stoically takes the bad news to Metropolis,
where a new transportation board expresses doubt that the idea can ever
work. In desperation, Idea Guy approaches Developer Guy with a radical
new idea – use Extreme Programming to trim cycle time and get
the product out the door faster, cheaper, better. Developer Guy threatens
to quit. Idea Guy finally concedes that the delays are inevitable. Big
Corp loses the Metropolis contract. The Sunny City RFP is in limbo as
city officials there rethink their requirements. Focusing only on the
“bus stop estimator”, the release finally occurs in July.
River City officials are pleased with the result and decide to deploy
a system along a popular bus route to see if consumers will actually
use the “bus stop estimator.” Results prove disappointing
and River City cancels the project.