Classic new product development starts with features, functionality, and quality. Customer needs are surveyed and researched, requirements are written, prototypes are designed and analyzed…and the entire effort is either time-boxed or budget-boxed, depending on the industry. Good companies know whether time or cost is more important, but those are generally secondary to actual functionality or final product qualities.

I’d like to propose that for emerging and innovation-driven markets–like high tech–features and functionality represent the least important corner of the triangle. I think that some of the most innovative companies start by specifying the cost and timeline for new product development, and take a more hands-off approach to actual functionality. Companies like Google and 3M, which explicitly require employees to devote time to personal projects (PDF) already do this. Events like Hackday are even more explicit.

The different product development focus looks a lot like Agile software development methodologies. Instead of asking, “What should our new product be?” it asks, “What cool things can we do cheaply?” I think this makes the most sense in innovation-focused markets because these are places where we know the least about what customers really want. The less you know about what customers really want, the less value you can expect to get from a product specification process. Agile methodologies, similarly, teach us that it’s unlikely you’ll get anything right on the first try, so you’d better make each iteration quick and cheap (Google cache) so that you can get it in front of a customer as quickly as possible.

Even though this kind of product development may make sense for technology companies, it will be seen as a challenge to the traditional product management role. Their job no longer consists of telling people what to do. Since essentially they’re being handed stuff (Engineer: “I noticed that with only a few more lines of code, our Wiki software would make a pretty good MS Project killer!”) they become advocates, influencers, cajolers,  and evangelists. It becomes a zen role: each new product becomes a surprise, an opportunity you cannot own, and a leap of faith to let others do what you had believed was your job.

The reward is profitability. The high-margin reward of being “first mover” can be overwhelmed by the sunk costs of the product development process. Explicitly starting by minimizing costs and decreasing cycle time means your margin of success is lower.

My point, and I do have one, is that price is a signal, a story, a situational decision that is never absolute.

Yesterday I also said that most of your customers will be more sensitive to features and scheduling than price (and that those are the only three possible project requirements). Seth says:

And yet, Easy411 provides precisely the same service to callers for half the price. Why doesn’t everyone use them? Because it’s not just the price. It’s the hassle and the set up and the “I didn’t get around to it” nature of saving a few bucks.

Here’s everything Seth had to say: Seth’s Blog: Most people don’t really care about price. If Seth agrees, then I must be right!

1. Understand how their company “makes money”–their corporate strategy for success and metrics for determining progress towards that goal
2. Be able to evaluate requirements (i.e., cost, schedule, and features) in terms of the above metrics and goals
3. Be able to cost and price and understand the difference between the two

What is the difference between cost and price? Why would price be different than cost? Cost is a description of the impact on your resources of doing something–of meeting a set of requirements. Price is a means for communicating your priorities and preferences to those whose requirements you are asked to meet.

From the perspective of managing a project, there are only three requirement: Cost, schedule, and features, and it’s accepted project management practice that only two of them can be specified at a time (as engineers say: “Better, faster or cheaper–pick two”). If you understand your corporate strategy you can help your customers understand which two are the most important. For example, in the retail financial services world, IT costs are often only a small part of the budget for a new product launch. However, the IT portion of the project can still be on the critical path–if the IT part is delayed or doesn’t meet the feature and quality requirements the opportunity cost is great. It would then be reasonable to assume that the sponsoring business group would be willing to pay a high premium–possibly above estimated costs–to guarantee that their feature and schedule requirements are met.

It’s not enough to be willing to adjust prices to meet feature and schedule requirements. You need to be operationally prepared to accept the work. This is done by maintaining a level of staffing slack above your expected work level. Your level of slack bounds your capacity to meet new requirements and new projects. How much slack is required?

That’s a harder question than deciding how much slack to pay for. One way to calculate it would be to identify the corporate cost of missing features or delaying delivery. The cost to the company should approximate the price they’d be willing to pay to avoid it, which is to say, the price they’d be willing to pay for slack.

Interestingly, it’s likely that maintaining slack across the team and the IT organization will probably lower overall costs, but my theory that IT is just discrete manufacturing probably deserves its own post.

Why can’t an organization be responsible for all of its IT needs? In most cases it would be absurd. Few companies write their own word processing or email software and few companies hand build their own servers. Why not? Three primary reasons:

• It’s relatively easy to specify accurate requirements for the products. For example: 2U, 2 CPU rack server, 4GB RAM, 137 GB HD in Raid 5 array, or, even easier, MS Office 2003.
• Your organization’s business plan and strategic objectives are unrelated to the specific requirements. Moreover, other organizations are looking for materially indistinguishable products: Office 2003 is Office 2003.
• Product improvements are do to a very large user base. The fact that Dell sells billions of servers or Microsoft millions of copies of MS Office means the cost of ongoing innovation can be spread across a large number of buyers.

These are fairly obvious examples – no one needs to justify purchasing off the shelf hardware or software for general business tasks. But what about more specialized tools? How well do my three criteria above work for your typical medium sized business:

• For the most part, specifying phone features isn’t so hard. Voicemail, call forwarding, conference calls, transfers, call parking, speed dial, temporary outgoing messages, number rollover, and number delegation should just about cover the software. On the hardware side, you should have speakers phone, handsets, headsets, independent volume for all three plus ring, multiple ring tones, and voicemail indicators. A small display to make dialing and menus easier would be highly desirable, and a larger display with soft keys to help navigation is a nice to have. That wasn’t so hard.
• Most company’s business plan doesn’t say, “We will leverage synergies and produce class leading value by installing the best gosh darn phone system in the world. That is, unless it’s your job to install phone systems or you run a call center. But hold that thought. The truth is, you don’t care if your closest competitors all use exactly the same phones as you – that’s not going to make or break your bottom line. In fact, if you plan to hire folks away from your competitor, if they don’t need to learn a new phone system you might get marginally more value if your system is exactly the same as the one they just left
• Finally, phone systems change over time. Hard as you might work today to build the perfect phone system, you may start missing features like VOIP, forwarding to cell phones, and the ability to listen to messages via email. If you’re responsible for building and installing the system, you’ll be the one responsible for upgrades.

Some organizations, of course, will care more about their phone systems than others. If you run a call center, your system is part of your workflow and presumably part of the value you offer your clients. You may not be the one to build and install it, but you would expect your IT group maintain some level of expertise in this critical product. Properly specifying the project will be a tremendous undertaking and you’re probably not going to get it right. You’ll probably end up with a customized solution. Moreover, compatibility with your workflow may be more important than the addition of new features over time.

Basically, the IT department, in terms of taking on new projects, should focus on those that will have the greatest impact on the organization. These will be the ones tied most directly to the organizations value proposition–it’s understanding of the means for success. Typically we can expect these to look similar: they will be difficult to specify and they will look markedly different than a similar product that your competitors would want.

Are you investing in the correct IT projects? Are you outsourcing the rest?

Eclectic Bill: TOC Analysis of Technology