Earlier I wrote about general lessons from Apple, but now that i've had my iPhone for a couple of weeks, I thought I'd talk about some of the lessons from this new product. I believe there's much to learn (good and bad) from virtually every new product introduction, but this one is a particularly rich example.

First, I think the biggest lesson from this product is how important it is to understand that you don't get great, innovative products like this from focus groups. Specifically, you would never come up with an iPhone by listening to investors, users, customers, the media, or industry pundits. The key reason why is that none of these people had any clue that most of what Apple designed was even possible. Unless you were on the bleeding edge of several areas of both hardware and software technology, you would have no idea that touchscreen technology had progressed this far, or sensors with these capabilities were now cost effective, or that processing speed and display technology could enable the user interactions necessary for the desired user experience, to name just a few of the many examples.

I remember when the iPhone was first announced how so many of the pundits dismissed the idea that a touch screen could possibly form the basis of all user input, especially for typing. Most people had experience with the Treo, and how hard it is just to dial a phone number, so they naturally assume that's a doomed approach. But Apple knows that their job is not to listen to consumers (or the press) and build what they tell them to, their job is to understand the unmet needs of their target users and invent a product that meets those needs. They have the product managers, designers, software and hardware engineers that are responsible for understanding the latest technology available, and for applying these technologies to come up with truly good solutions to these problems.

I can't emphasize this enough: If you ask a group of users what they want they'll just describe (perceived) incremental improvements to what they already have and what they assume is possible.

Second, I think the company demonstrated admirable discipline in keeping the focus on their primary target users and not trying to build one device for everyone. A 25 year old telemarketer in LA does not have the same needs from a mobile device that a 50 year old Sand Hill Road Venture Capitalist has. All the people that are so anxious to compare a blackberry to an iPhone seem to be missing this point. While for selfish reasons I might love some of the features of Blackberry/GoodLink on my iPhone, that doesn't mean that I'd recommend that Apple go rush to layer these in to this device. That might be what most companies would do, but Apple knows that if you try to make one product for all, you end up with a product liked by none.

Third, congrats to the product managers for keeping the functionality so minimalist. Most users won't perceive the functionality as minimalist, but that's the point. Their applications have a fraction of the features of their counterparts, but on the other hand, what is there is accessible and understandable. A great example of less is more.

Fourth, this is one of the single best examples of the value of great interaction design that I've ever seen. Yes, the iPhone has great engineering, and yes, the iPhone has great visual and industrial design - the visual design in particular is exceptional even by Apple standards - but the real key to the device is the interaction design. Try the visual voicemail, or the browser, or the contact list. The interaction design is near flawless. They have done an amazing job of matching the user's conceptual model of these objects. No menus, do deep hierarchies, just a very simple and consistent model of interaction that in nearly every case is natural and intuitive. Many product people don't even know what interaction designers do (and their product reflects it). This product should go a long ways towards educating our industry.

Fifth, in spite of the job Apple has done, this product is yet another example of why dependencies suck. The iPhone depends on AT&T's Edge network, which is frankly awful. Much of the device is not very useful unless you are in a WiFi zone and can bypass the AT&T data network. I fully expect that AT&T will gain several million new customers over the coming months, but I hope nobody thinks it's because of anything they've done. The iPhone will be a dramatically more useful device in the many countries of the world that have true 3G networks, and they don't have to depend on the WiFi workaround.

Finally, the jury is still out on whether Apple will enable third parties to develop the range of applications that are now possible. I hope Apple looks at what Facebook has done in this regard. This device is the first truly useful mobile application platform, and while Safari-based web applications are already running and useful, there is also a strong need for iPhone native applications, so that others can create the types of applications that Apple has done with YouTube, Mail, Stocks, and Weather. I think this point will ultimately decide the future of this device. If Apple won't open it up, then someone will copy much of what they've done, but with a platform that is open, and the application developers will go there, and all it will take will be one or two out of the thousands of applications developed that will drive adoption of that platform. Does that scenario sound familiar?

The only other point I'd like to mention is more of a marketing/positioning point. I'm not sure about the positioning of this device primarily as a phone. The device is much more than a phone, in fact, I'd rate the fact that it's a phone (and I consider it the very first truly good phone interface out there) as secondary. The device is much more of a complement to the personal computer. It's a bit like bringing my Mac with me everywhere I go. Perhaps more importantly, it is also the first mobile device that I can imagine being the only computing device many people have. Especially in developing areas of the world, this device could truly be a substitute for a personal computer.

Email to a friend

Sign up for the free newsletter here.

Even though we've been estimating project costs since the beginning of software, it's remarkable to me how much confusion remains. I think the root cause of this confusion is that management needs cost information very early in the process, yet engineering doesn't have the information it needs to do a reasonably accurate estimate until much later in the process. The result is either premature estimates that prove wildly inaccurate, or surprises because people had different assumptions all along and when the accurate estimate comes in, management has a severe case of sticker shock.

Here's the process that I advocate. It is intertwined with the product development process I advocate, but it can be applied in most.

Recall that I strongly encourage all product efforts to start with a 10-question opportunity assessment (you can read more about these questions at www.svpg.com/blog/files/assessing_product_opportunities.html). This is what the management team uses to decide whether this is a problem worth trying to solve. There's no solution yet, just a problem, and an opportunity. But for most teams there's a need at this stage for a very preliminary estimate of scoping. Of course, since there's no solution spelled out at this stage, it's going to be very much a SWAG, which is why I recommend that the estimates at this stage are limited to "Small," "Medium," or "Large." It's usually fairly clear at this granularity what the cost will be, although there will still be occasional surprises.

If the opportunity looks good relative to the estimated cost, the management will likely allow the project to proceed to defining the solution (the spec). It is at this stage that the product solution is spelled out in detail, ideally with a high-fidelity prototype that you validate against real target users with prototype testing (see what I mean by a prototype-based spec at www.svpg.com/blog/files/revisiting_the_product_spec.html).

All through the process of coming up with the solution, the product manager and designer should be including a member of engineering to evaluate the various options and estimate costs for the different alternatives. That information is then considered by the product manager and designer and the product is adjusted as needed. But at the end of the spec process, there should be a very detailed and high-confidence estimate based on a detailed description of the product proposed to be built.

At this stage, the management team has a detailed product spec, and a corresponding high-confidence cost estimate, and they should be able to make a final decision on whether to proceed to build this product or not. It may be that the solution turned out to be more complex and expensive than they thought, or they might not like the actual solution, but if they do proceed the whole product team knows the cost and the product they'll get for that investment.

So to summarize, I'm suggesting a preliminary estimate at opportunity assessment time, followed by a detailed estimate that accompanies the final product spec.

As an aside, I also believe in tracking the cost of changes to that product spec and schedule ("churn") so that the organization understands the cost of change, and can improve by always trying to minimize this churn.

Email to a friend

Sign up for the free newsletter here.

How many of you understand the economics of your product? Do you know your exact revenue model? Do you know the total costs of your product? Do you know how much you pay for each new customer? Do you know their lifetime value to the company? Do you know the return your product has generated for the company?

In my experience, most product managers, especially technical product managers, have only a very shallow understanding of how their product (or their company) makes money. Especially those of us that came to product management from engineering.

I learned a long time ago that I could benefit a great deal from making a friend in the finance department. At every company i've ever worked at I have asked the CFO for someone that could help me answer these questions, and it always amazed me at how willing these people were to help, and how much information they had available for those that asked.

I've found that my friends in finance can help with three big things.

- Understanding Your Product

Sit down with your friend and ask for help determining and evaluating the financial aspects of your product, starting with the questions I posed above. If you have partnerships, read the contracts. If you license technology, look at the agreements. Ask your friend to help you assess your product. Is it carrying its own weight? Is it a good investment for the company? What trends does your friend see? Is the product heading in the right direction?

- Understanding Your Customers

While we typically have good tools for understanding how user's behave on a web site (via web analytics), the finance department often has a wealth of additional information on the actual customers, accumulated from transaction histories, payment information, customer data and management reporting. You both of course need to be sensitive on what information you can view and how you use it, but in terms of understanding your customers it can be extremely useful.

More than once I've uncovered information about my products from the financial staff that truly surprised me, and exposed fantastic opportunities. One time in particular I remember asking my friends why nobody knows this, and he replied "because nobody asked." Realize the life of a finance person is largely thankless, and driven by extreme deadlines ("our quarter closes on Thursday and we're announcing earnings on Monday!"). I also have this theory that people in finance are often fairly quiet, and not the type to come to your desk advocating product opportunities. Usually, you've got to go to them.

- Preparing The Business Case

You've got a great idea, but you're not sure about the business case. Your friend in finance can help. You'll need to provide most of the inputs, but your friend will know how to put together the case. If it's a good case, you'll also find that having someone in finance that has studied the economics of the potential product can be a big help with senior management.

So go make a friend in finance. You need the information they have and their help in interpreting the information and putting it to good use. I think you'll find that these people want to help their company, and appreciate the opportunity to do so.

Email to a friend

Sign up for the free newsletter here.