By Alyssa Dver
If your organization is experiencing growing pains, scope creep, scalability surprises, stressed-out staff, and impatient customers, you’re probably trying to take your software product from prototype to production. You secured seed funding and an initial customer or two, and now you need to grow your base to bring in some real revenue. It is a very exciting time, but you may not realize that the light at the end of the tunnel may be a train.
Garage prototypes serve as proofs of concepts. They show enough functionality to demo well, but in reality, they lack the internal wiring to make an application work in the real world. In other cases, new software companies form after a successful custom-developed application is built for a single client. This one-off is used as the base product for a broader, commercial market. Sometimes a software tool used to deliver a primary service becomes the stem cell that triggers commercial "productization."
In all of these incubated cases, new customers using the software find problems quickly when they try to use it in their own unique environments. The system performance may not be acceptable with a large number of users or high volumes of data, or perhaps the user interface is too specific for the original client and doesn’t make sense to anyone else.
New hardware and software platforms, back-end integration complications, subsystem compatibility, and a host of other variables raise their ugly heads during the production development phase. Plus, having an increased user pool pound on the software inevitably means more bugs will be found as these eager new users push the freshman application in ways that formal quality assurance (QA) testing didn’t.
Igor Tsinman, a seasoned CTO and partner at development company Sitrus, has seen it all. "When software companies move from prototype to production, there is an avalanche of demands on the development team," he explains. "They need to address critical bugs while improving system performance, adding new features, correcting user experience (UX) usability, integrating with other systems, or opening up the API to allow for third-party integration. And all the while, the investment of time and money needs to be aligned with the business goals of the company."
Indeed, this is not a task for shy or new development managers. It can be close to impossible to figure out the right priorities during this speedball phase of growth.
Most product management classes and books give a generic, any-lifecycle-phase approach to product development and requirements analysis. However, taking a product from prototype to production is unique because it involves very rapid—and perhaps even rabid—development of product requirements that aren’t always quantifiable. It’s hard to nail down how much is enough in terms of performance, availability, and UX, and even harder to predict the return on investment (ROI).
Therefore, with the wisdom of recent experiences, veteran software experts provide their best survival tips when transitioning from prototype to production.
1. Be clear about your business and product objectives before touching the code.
Right from a potential movie screenplay, three college guys decided to build a suite of small business mobile development tools and services. Though still a fresh 23-year-old—but with more wisdom than most software veterans—Andrew Gazdecki, founder/CEO of Bizness Apps, says the key to his company’s quick success was focusing on four clear markets and the features for each of those markets that had a clear ROI.
"We gathered as much marketing feedback as possible in the beginning. We consciously limited the feature set to the real world’s needs and then tested it all directly with actual customers," he says.
2. Involve your users in QA and product decisions, but do so objectively.
The open-source code catalog and community Koders.com is managed by Black Duck Software. The users of this popular site provide a tremendous resource from which to draw ideas and solicit help in testing new versions Code Sight, of Black Duck’s enterprise system.
Bill McQuaide, EVP of products and strategy, and Jim Berets, VP of product management, Black Duck, rely on these ideas and support, but they acknowledge their biggest challenge is prioritizing. They developed a way to analyze clusters of feedback to ensure they address "the meat of the market needs."
"It can be hard to decide the best direction to go when you get so many good ideas that you are tempted as a company to shove just that much more into a release," notes Berets. "We work hard to communicate both ways with our community of knowledgeable users as well as maintain management patience to ensure our work and plans remain on target with our company vision," adds McQuaide.
3. Establish a product management and development process.
Scott Simpson, director of ITCambria Consulting, leads the technology practice of the executive coaching and assessment company whose technology platform is tailored to fit perfectly into a client’s business environment. However, in the beginning, Simpson noted that the company was developing one-off solutions for each client that became impossible to manage and maintain.
"Since we aren’t a software company by charter, we didn’t implicitly have a large staff or set of procedures to manage the software that we develop as part of an overall consulting engagement. We quickly realized we needed a disciplined approach to address clients’ requirements, but we also needed to ensure that our development decisions were always in Cambria’s own best interest. That balance is only achieved by our commitment to a process that weighs all the opportunities against the development costs and time needed. With that process to lean on, we make more confident short- and long-term decisions that have clearly contributed to the growth of our software business."
4. Your staffing needs will change—from developers to the CEO.
Interviewees repeatedly reported that personnel skill sets change over time. Technical founders often move aside to allow for more seasoned business executives. Domain expertise helps in prototyping but doesn’t help when the scalability or user interface fails. Cowboy coders who can jury-rig a quick bell or whistle rarely have the patience to document their code and write test beds to ensure that the code works in all environments.
Stefan Piesche, CTO, Constant Contact, suggests that the developers working on a prototype not be the same people who build production software and maintain it. "Make sure you have a team with the right talent, not just the right skills. When we build production versions of our products, we need people who can deal with chaos and ambiguity given the changing product requirements."
With the new revenue-generating customers breathing down a company’s neck for more reliable software, investors can become edgy when the development staff is exhausted. Dealing with this emergency situation can mean hiring more internal development staff or considering an outsourcing/near-shore or other contract development partner.
Sitrus’s Tsinman says his company is frequently called on to help put out a development fire. However, he also admits that his company is often prejudged by the abundance of outsourcing companies that lack production system experience or are just not interested in the long-term success of the client.
"If an outsourcing company isn’t willing to invest the time up front to really understand your company’s business objectives and culture, it is a red flag," says Tsinman. "A good outsourcing partner is in it for the long haul and as such, needs to complement your existing processes. It shouldn’t matter where they are located, what code they claim to be able to write. The key to every project we’ve worked on is having a fluid relationship with the in-house development team so they can leverage our long-term experience developing complex and commercial production-quality applications."
5. Be prepared to throw out your prototype.
Typically, less than 5 percent of your initial prototype code will remain in the product over time. WordStream is one example. It came about as a result of then-consultant Larry Kim delivering analytics software as part of the search-engine marketing service for multiple customers, a job in which he discovered a need in the market with no other apparent solution. Kim proudly says that throwing out the prototype is a "badge of honor" among successful entrepreneurs because it means you have outgrown the purpose of the initial prototype.
"When you are ready to cross the product development chasm, you need to architect the commercial version of the product to accommodate luxury—or at least less visible features, such as scalability, user interface improvements, administrative support for installation, and usage metrics. In the beginning prototype phase, you don’t even have time to dream about these problems. You know you have made it through that phase when you need to then address these less market-driven requirements, and you even start to anticipate them."
Just as a high school or college sophomore can no longer be excused for his or her ignorance and irresponsibility, so too a successful software business eventually must focus, perform, and mature