Home
For Entrepreneurs
For Investors
Investors Directory
Industry Events
News & Updates
Articles
Glossary
Resources
Partners
Featured Companies
Advisory Positions
About Us
Contact Us
 
 

 

 

Why Should VCs Give you a Dime?


By Trudy E. Bell, Arthur P. Cimento, and Jeffrey C. Sinclair

You look around the conference room table and feel your heart quail. This wasn't at all what you expected when the chief engineer tapped you to be part of the highly visible pilot team spearheading the company's reorganization of product development.

Yes, you knew that customers had been complaining that products were overfeatured and late to market. And you knew that to solve those and other problems, the company had committed itself to making product development a multifunctional team sport, instead of primarily an engineering-driven process. But until this moment, when you sat down and looked around the table, it had not sunk in what multifunctional truly meant.

Seeing colleagues from manufacturing, operations, and maintenance was no surprise - you've been doing concurrent engineering for years. But what were those folks from marketing and sales doing in this room - don't they just write advertising and peddle products after they're made? And what about those two bean counters from corporate finance and purchasing? What could they possibly contribute to a product development effort?

You swallow.  With the high visibility of this pilot team across the company, you know your own reputation could be made or lost depending on the results from this motley crew. And now it's far too late to pull out. What can you possibly do to help ensure that the team is a success?

For engineers working in an organization, whose culture is the traditional one of people working primarily within their individual functional departments, the first experience of embarking on a project in a multifunctional team can be culture shock. But there are quick and useful ways to gain a new balance that will allow you to be off and running far faster than you ever dreamed possible.


Shift Into a Business Perspective

First, shift your perspective to recognize that - traditional corporate culture notwithstanding — product development and engineering are not synonymous. Viewed from a whole-business perspective, product development is the process of connecting customer needs with technical possibilities, and at a cost that allows the product to be sold at a price that the customer recognizes as value, and that allows the company to make a profit and grow.

In mathematical parlance, engineering is a necessary, but not sufficient, discipline for product development. After all, innovative products emerge not only from the engineering inspiration, "Wouldn't it be neat if ...?" but also from insightful perceptions of potential customers' latent needs. Entrepreneurs know well that product development is interdisciplinary, or they learn it the hard way: if they can't find customers to buy their clever gizmos, they're out of the gizmo business fast, regardless of technical superiority. That's why new companies are commonly started by several founders, rather than just by a solo technical genius: the technical genius needs partners to drum up customers, obtain financing, contract with suppliers, supervise assembly, manage order fulfillment, and satisfy the liability lawyers and tax man.

Second, shift your perspective again to think of yourself as an entrepreneur. Try to imagine yourself as CEO of your multifunctional team, and the members as your partners in a startup. Wouldn't you, as an engineer, just love to get your hands on the wealth of data your marketing partner may uncover by asking such questions as:

  • How are customers actually using current products (regardless of how the company thinks they should be used)?
  • Why do customers prefer competitors' products over yours?
  • Why do some potential customers buy neither your company's nor your competitors' products?

As far as the bean counters are concerned, as CEO you'll realize that it is not beans they are counting, but shareholders' dollars entrusted to you and your company for making more money. The fiscal responsibility of the financial professionals needn't put a crimp in technical approach (except, perhaps, where a crimp is needed — such as sounding an alert when the product is becoming so gilt-edged that customers are unlikely to buy it at the needed price). In fact, clever techniques for sourcing raw materials and tough, informed purchasing negotiations can be instrumental in lowering overall cost, so that your company can offer the new product at a lower price or with more bang for the buck compared with competitors.

Third, shift your perspective a last time to envision yourself as an entrepreneurial CEO, approaching a venture capital firm on behalf of your team for the next round of financing. Why should this venture capitalist give your multifunctional team a dime?

You Can't Do It Alone

Here's where you, as the engineer, realize that you need your multifunctional teammates as much as they need you.

As chilling as it may sound, venture capitalist firms want to know first and foremost how a startup plans to make money from an idea. They are more interested in management teams and complete marketing plans than they are in specific technological concepts. At the extreme, in fact, they have even been known to put a management team together first and worry about the engineering concept later. Before investing, venture capitalists want to see how you plan to identify customers and sales channels, as well as what your envisioned product will do. History is strewn with sad tales of brilliant technologies that never made a cent; what you want to do is marry a terrific technology with a terrific business plan.

Even if a venture capitalist firm likes a founding team and its concept, it will commonly starve the startup for capital. Typically, financing is awarded in several defined stages, starting (perhaps) with seed money to fund research on a fledgling idea, and culminating with mezzanine or bridge financing for an initial public offering of stock. Each financing stage is a distinct milestone at which the startup's progress, product, and operations are scrutinized. If the startup wins financing at any stage, the amount is usually just the minimum needed to get it to the next stage, and it's often less than the founders feel is necessary. If progress doesn't pass muster at any stage, the venture capital firm has the right to fold its hands and say, "Sorry!" Poof! The startup becomes just one more good idea that never made it.

Not only do staged financing and a shoestring mentality minimize the venture capitalist's risk, but more importantly, they keep the startup's founders focused on the essentials: getting this new product done, out the door, and into the hands of customers as expeditiously as possible. Historically, the starvation diet has worked well - in fact, there have been cases when overfinancing a startup has actually killed an enterprise as surely as overfeeding a plant. (One large-equipment manufacturer, for example, allowed its product development team so much flexibility and resources to 'perfect' its high-tech innovation, that it was 4 years late to market - and had, by then, been superseded by inferior offerings from competitors.)

Act Like an Entrepreneur

So, what does all this business perspective-shifting have to do with you, as a product development engineer in a large, established company? Many corporate elephants, feeling the nimble mice nipping at their toes and gobbling away their business, have been learning to dance by creating conditions for fostering entrepreneurial energy in-house. There are two basic techniques:

  • Multifunctional teams
  • An internal sing-for-your-supper venture capitalist mentality

In a vigorous startup, multifunctional teamwork happens naturally. All the founders are closely focused on a single product and everyone knows and respects everyone else's role. However, in a mature company, with hundreds or thousands of employees and dozens of product lines, effective teamwork among functional departments requires forethought and conscious effort, partly because people may not fully appreciate one another's corporate purpose. Multifunctional teams are an effective way of keeping engineers in close touch with customers and financial realities.

Moreover, in a vigorous startup, incentives are aligned. There is urgency born of raw need: the company cannot afford a mistake in concept or targeted customers or a delay in launch date, as the penalty may well be the death of the enterprise. On the up side, though, a market success could make all the founders millionaires before age 35.

In a mature company, however, incentives may actually be opposed. The development of a mediocre or poorly-conceived product may continue to be funded because of oversight, politics, or organizational inertia. If the product fails in the market - oh, well, everyone just works on the next concept. And if the product is a runaway success, employees might get only a handshake and a photo in the company newspaper.

In some large, established companies, this disconnect is changing. They recognize how powerfully employees can be motivated to high performance by keeping a venture hungry, requiring the passing of milestone evaluations before proceeding to the next stage of financing, and having the potential to attain Gates-ean riches. They also recognize that sharing a percentage of the true rewards can mean reducing the risks of poorly conceived products, as well as lowering the risk that top employees may walk to start up their own companies.

Some large companies (among them Ericsson, Microsoft, and Siemens) are realizing the value of seeing that each team member has skin in the game - that is, a substantial stake in the product's failure or success. On the up side, that means stock options, royalties, or other incentives. On the skin side, it means tying individuals' performance to the team's performance and increasing accountability for the product's market success.

Even if you're an engineer within a company not yet so advanced, take advantage of being in a multifunctional product development team to try thinking and acting like an entrepreneur getting ready to request the next round of financing from a venture capitalist.

At the first concept approval meeting, for example, focus questions not only on technical features but also on business issues:

  • What current or latent customer needs are being met by this new product?
  • What is the price point at which the customer will recognize value?
  • How can we get it to market?
  • Is it easy to service or is it a PITA [pain in the wazoo]? Or is it reliable enough not to need servicing?
  • What is the volume potential for manufacturing? How soon can we earn enough return to pay for manufacturing?

Be a Team Partner

Teamwork is as much about people as it is about expertise. Ideally, team members are chosen not only for their expertise and availability, but also (as far as is practical) for their personality traits and individual developmental requirements. Do what you can to influence the team leader to blend both experienced colleagues and promising new blood. Count your blessings if the team leader is a strong, empowered program manager, with the support and sanction of the company's senior leadership to call the shots without being second-guessed or micromanaged. And plan to learn effective leadership skills, if the team leader has the personality and wisdom to know that he or she need not - indeed, should not - lead in all transactions. On the best teams, authority is fluid, shifting from one team member to another in response to necessary expertise or tradeoffs.

Do all you can to make sure that the team's mission is clearly stated. Every member should understand the new product's market focus, performance requirements, cost constraints (both on product cost and capital cost for manufacturing), date of launch, and technologies to be incorporated. If the understanding is not clear enough that all team members are willing to have compensation incentives tied to the fulfillment of those objectives, then the mission is not clear enough to execute. Without clear guidelines, the project risks having the launch date slip because of endless dithering and rework over uncertainties in the concept, requirements, and execution.

Once the product is launched, resist any suggestion that the team should be disbanded immediately. Beyond the inevitable cleanup work that always needs to be done, your team's expertise should be kept intact in the event of customer complaints or product recall. Moreover, making the team responsible for after-launch glitches and successes anchors the accountability and credit where it belongs. For a PC-based product, a multifunctional team should stay together for a good 3 months after launch; for a product as complex as an automobile or aircraft, a year is not out of line.

Do all you can to create team cohesiveness. Especially if your organization's culture is strongly functional, lobby in favor of physically moving your team together, out of everyone's respective departments. Product development is not only a team sport, it's a contact sport. After all, the whole point of having a multifunctional team is to make cross-disciplinary communication easy - just as it is in the garage of a startup. Evidence abounds that the most fruitful interactions often happen, not in formal meetings, but in chance encounters. Proximity encourages chance encounters and thus informal communication.

Most importantly, do all you can to make your team's effort fun - a much under-recognized motivator of high performance in established companies as well as startups. "Do you really want to know what makes Silicon Valley tick? I mean, deep inside, at the core?" asks Christopher Meyer in his recent book Relentless Growth: How Silicon Valley Innovation Strategies Can Work in Your Business. "The truth is ... it's a ball! Hard work combined with hard play - at every level, from executive down and back up again."

 

Source: http://www.todaysengineer.org/archive/v1n4vc.htm

 

 
Home | News | Terms of Use | Privacy Policy | Contact Us
Copyright 2004-2008 VentureChoice Inc. All rights reserved.