All over the web and in all the product management communities, there are articles and discussions about gamification. If you’ve been offline for a while, gamification is about applying design and development efforts to software in a way to make it more engaging, more “fun.”

Not only have whole applications been born under the premise (i.e. Foursquare), but gamification has also had great impact in some of the more traditional business software, (ie. Salesforce.com) allowing for more interaction and amusement when performing daily tasks.

I’m all about having more fun in my interactions with technology, and can truly appreciate making the more mundane less so; but, I believe sometimes we have taken the concept of gamification too far.

Not every piece of software or every interaction within should be designed around fun. Stanford professor Elizabeth Corcoran, in her book on the subject, “The ‘Gamification’ Of Education”, suggests that the gamification of businesses and virtual worlds is creating an expectation among people that real-life interactions follow simple mechanics and some disillusionment when they do not. Are we making our software more of a toy than a productive tool?

I recently heard of a software company’s UI meeting, held to introduce the upcoming planned release to the internal audience, where the  discussion quickly went from what the planned for now to the planned for later. In the “planned for later” talks, the designers were sharing their vision for the upcoming UI changes, which were focused on including more opportunities for social interactions. The problem? No one had talked with more than 1 or 2 current customers to find out if this is what is truly needed or wanted.

Conversations need to start with the market, not just customers. Does your market want to play a game when they are in your software? Will it help them do their job better? More effectively?

Luke Hohmann, with his company Innovation Games, does great work in promoting playing collaborative games with your customers to build  engagement. He states that engaging customers in a well-designed Innovation Game frees them up from the constraints of typical focus-group sessions and delivers deeper, more accurate information than is available through online surveys or other tools.

There are some very successful elements that need to be copied.  Gaming elements do and should belong in SOME software. Luke’s reasons and use make sense. In consumer-facing sites, I support using gaming elements to make the site more engagement, building more loyalty, etc. In business programs,  I can no longer remember the “old” training programs where you didn’t even see your status on the module much less your achievement. Gaming made training more fun. But, once you start entering the enterprise software realm, gamification is an area that needs to be evaluated carefully.

Gamification elements that are added in by designers because they are the latest and greatest, will quickly get subjected to the sideline and prove to be a waste of your time and effort. In the competitive software market, time and effort need to be focused on those areas which deliver the differentiation. And, it might not be about the game.

(Please share this on Twitter, LinkedIn and even Google+: “Not Everyone Wants to Play Games” by@jidoctor: http://wp.me/pXBON-36h #prodmgmt #gamification”)

Related posts:

1. Games executives play: Guess what's in the envelope
2. Book Review: Innovation Games
3. I clicked "Play", mommy
4. On Product Design

By Jennifer Doctor

This is a simple post about being simple.

I was thrilled and honored to have a visit by my good friend, Jim Holland, for the recent Product Camp in Minnesota. While he was here, he scanned my business book shelf and borrowed a book, my copy of Seth Godin’s “Poke the Box.” Jim enjoyed the short read and wrote a nice blog post based on his learning from it; in exchange, he brought me a small token gift, a simple non-descript cube that has somehow changed my life.

The product is the One Less Drop by Heckler Design. What does it do? It’s a cord keeper for my iPhone (though I am sure it will work on other devices.) This 1 inch cube has two channels in it; one is on the top and one is on the bottom so I could manage two devices with one cube. By placing the cube on a table or desk, the channels hold your cords without letting them fall to ground. Brilliant.

What’s the use case? I keep a power cord for my iPhone on my nightstand, and I fumble around looking for that cord every night I don’t anchor it down with something – often it was a bedside book, the alarm clock, another knickknack – basically anything already on the night stand, or else I am fumbling around on the floor looking for the cord when I am tired and all I want is some sleep… and I do this all so I can simply plug in my phone to charge it up overnight. Now, this simple cube means no more fumbling around on the floor in the dark. Brilliant. Do you take your smart phone to bed and plug it in right by your side, so that you never miss a call? Am I the only one with a problem to solve here? I want to think I’m not.

I never thought a one inch square cube could make me so happy, yet I was very excited by this. Why? Because it solved a simple problem and, as a product manager, we are always searching for solutions. What did I learn from this cube’s design? A simple rule – sometimes the smallest aggravation can be solved by looking a simple solution. The solution doesn’t always need to be over-engineered just because “we can.”

In our world of developing products, we all too often look for elaborate solutions. And, worse yet, we put all too many features in our product hoping that it solves all the problems our market may face. What if we simply stepped back and tried to simplify our product instead of building it out to solve many of the world’s problems? Take a step back and look at your own product portfolio. Have you been trying to solve the world’s problems with everything you have added to meet everyone’s interests and desires; or, are you trying to simply solve the basic problem in the easiest and most basic manner? If you don’t know, ask the market and your customer how simply they want their problem solved. The simple way is always preferred.

I know that I will be sleeping better tonight knowing exactly where my iPhone cord is without having to fish around for it when I am exhausted. Thanks, Jim.

(Please share this on Twitter, LinkedIn & even Google+:  Make it Simple by @jidoctor –  http://wp.me/pXBON-33q #prodmgmt #design #ux)

Related posts:

1. Honey, I bought the Phone. Confessions from the Cambridge Apple Store.
2. New Year’s Resolutions – A few simple ideas
3. OnProductManagement plagarized!
4. If Steve can do it…

Note: This is a guest post by Fred Engel. If you want to submit your own guest post, click here for more information.

I was attending a feature set review the other day. As usual there were two camps each with a strong attachment to their solution. Not having a strong opinion on either side I asked, “How would someone succeed or fail with each of the options?” To my surprise, the response I got was

“Let’s just build one and see. In Agile, you build first and ask questions later. It is just impossible to think this stuff through, which is why you build.”

Now Einstein came up with the whole relativity thing using Thought Experiments. Surely our problem is not as complex as that, I argued. Besides, have we tried to figure this out? Do we know what is well understood and what is not? This line of reasoning was not being bought by the group. They wanted to build as a way of figuring things out.

What is wrong with “just building it”?

Building anything is costly in time and money and while it feels like progress, it is not. Just because something is being built does not mean there is progress. Progress implies forward movement towards a goal. Without out well thought out steps, the effort may not be progress but just movement. As discussed below, “just build it” is one of the tools in the arsenal and should be used after the thinking is complete.

What is a thought experiment?

A Thought Experiment is a fancy way of saying: “think through the various cases and scenarios of how things are going to work”. Thought experiments postulate different cases that are expected and think through the outcome. These “dry runs” are the cheapest, fastest ways of making progress for a broad set of problems. Usability walkthroughs are an example of this. Test driven design is another example. The process does not have to be formal, although it does need to provide good coverage.

One should always use Thought Experiments

There is never an adequate excuse for not using the brains in our heads to think things through. Here are some benefits of doing thought experiments:

• Save time and money
• Allow you to bring other people into the solution because you understand it better which will lead to you being more convincing.
• Make you to understand the problem better. Working out the details in your head and on paper really does allow you to simulate doing it for real.
• Solve the problem and give you a solution.
• Bring clarity to what the real issues are. If you do thought experiments you will figure out what is easy and what is hard. You probably will discover what actually does need to be built and tested empirically.
• Allow you to assess risk in the project and allow others to see how hard the hard parts are.

There are times to “just build it”

There are certainly a number of problems that can be solved best by experiment. It is after the thought experiment has been worked out that one can consider actually coding up the solution. The default should not be “just build it” but rather “here is what we should build and why”. Good reasons to “build it” include:

1. There are some key complex pieces that need to be built to understand the feasibility of accomplishing the task at hand. Complex algorithms dealing with real data are a great example of this.
2. New usability ideas. There are so many examples of good human interfaces that not learning from these seems wasteful. Know what you are doing that is new.
3. What you want to build is simple and much easier to do than to do a thought experiment on. This case rarely exists but is far too often used as an excuse for not thinking in the first place.
4. The people who need to be convinced will only be convinced with a working prototype. This is an unfortunate, but necessary, political answer to a real problem. “Seeing is believing” is sometimes the only way to understand or to move forward.
5. When you really do not understand the dynamics of how something would be used, it is time to build.When you are just prototyping to get some understanding of a new paradigm.

The Product Manager (or owner) needs to drive this process and guide everyone away from just building.  Engineers have a strong desire to get moving and start building.  If the Product Manager/Owner has done a lot of the thought experiments early, the arguments of what should and should not be “just built” will be much easier.  The challenge is to have the strength of character to force more Thought Experiments.

—-

Fred Engel is founder and CEO of Westerly Consulting, a management and advisory consulting firm based in Rhode Island.

Tweet this: Build vs. Think – The Need for Thought Experiments in Product Development http://wp.me/pXBON-31y #prodmgmt #innovation

Related posts:

1. Strategy, Innovation and the Need for Experiments
2. Agile/Scrum Software Development and Product Management
3. Forget research, let's build something! – Redux
4. Agile/Scrum Software Development and Product Management part 2

By Saeed Khan

Not all features are created equal. Not all features are useful or evident upfront. The value we derive from products can be multi-layered or multi-faceted.

In his article – Come for X, Stay for Y – Braden Kowitz eloquently writes about the concepts of Apparent value and Discoverable value. He writes (using Gmail as an example):

• Apparent value — This kind of value is easy to explain and gets users to sign up. It fixes a pain-point customers already experience. It’s typically better, faster, cheaper. In Gmail’s case, it was storage space.

• Discoverable value — This kind of value appears when benefits are delayed or when a product requires users to develop new habits (which takes time). It also appears when many slight improvements combine to make a big difference in the experience. This kind of value is powerful because it keeps people around. For Gmail, this was search and conversation view.

When you think about your product or service, do you consciously thinking about how you deliver value in these ways? What are the immediate needs — BTW this is the stuff that is typically marketed — that are being addressed, vs. what are those needs that will be addressed later on through discovery.

As a non-high tech example, take a look at the picture of the bridge above. The Apparent value of the bridge is to enable people to safely cross the water without getting wet. But the Discoverable value is the view of the river you have once you are in the middle of the bridge. And you’d only discover that once you were half way across.

Read the whole article as Braden discusses several companies and products — such as Zynga and Apple — who understand this distinction and implement it well.

Saeed

P.S. I prefer the term emergent value vs. discoverable value, but that’s just me.

P.P.S. There’s another value — hidden value — that you typically want to avoid when building products.

Tweet this: Apparent value vs. Discoverable value. Why both are important. http://wp.me/pXBON-319 #prodmgmt

Related posts:

1. What's the deal with Personas?
2. Little features and a lesson for Product Management
3. Worth Repeating: When Form Doesn’t Follow Function
4. Lessons from Harry Potter

Tweet this: Simplicity and Elegance Require Deep Attention to Detail – http://wp.me/pXBON-2Wh – #prodmgmt #design #innovation

By Saeed Khan

There’s a mantra these days (or does it qualify as a meme?) in product design that simplicity is critical and complexity should be avoided. The KISS principle — Keep it simple stupid – has been around for a while, but clearly in the last few years it’s come to the forefront of design thinking.

When building software products, simplicity does not mean simplistic. Simplicity in design requires sophistication in thought.

There is great tension between what’s easy to do and manage with technology, and what’s easy to do and manage for the user. Unfortunately in many cases, the former wins out over the latter.

Designing for the machine

I was recently talking to a friend of mine who was working with a database application. He had to write some reports using data the application had stored. Without getting into gory details of the database schema, let me say that the application was a job/task tracking application and amongst other things, for each particular task, it stored the time when the task started and the time when the task finished.

My friend needed to aggregate the total time taken for certain tasks and write out the start/end times of various tasks in a report for someone to read. Now here’s the kicker — all times stored in the database — including task starting and ending times — were stored as milliseconds from January 1, 1970.  By the way, the application itself is only about 3 years old.

He told me that he had to write some funky SQL to convert those times to something human decipherable. I asked him if he knew why the data was stored that way. He said he had contacted the developers of the application and was told that not only was this a standard way of storing date/time info (Unix Time?), but given all the data/time formats and representations out there, they couldn’t know what people wanted so they gave the users “freedom” to choose.

I had to smile at this last sentence – they were giving the user the “freedom” to convert a millisecond date/time value to any format they want. This example, in fact, illustrates simplistic thinking and a complete ignorance to detail. It focuses on coding to the machine’s bias and placing a burden onto the end user.

Designing for the human

A great counter-example — and here’s a mandatory Steve Jobs story — is an incident that is generally known as “Rounded Rectangles“.

In short, back in 1981, when developing the code to draw graphics for the original Macintosh, Bill Atkinson wrote some code that very quickly drew arbitrary circles and ovals on the screen. OK, for those of you young folks, this may not sound like it’s anything significant, but 30 years ago, with CPUs that completely SUCKED at any floating point arithmetic, this was a feat.

NOTE: Remember, plotting circles normally depends on formulas using pi or trigonometry (sin or cos of an angle), both of which require decimal calculations.

When Bill showed his circles and ovals to Steve Jobs, Jobs’ response went something like this: That’s great, but can you draw rectangle s with rounded corners?

Atkinson was taken aback. First, that would be hard to do. And second, why would anyone care about rounded corners on rectangles?

Jobs’ responded that rounded rectangles were everywhere, and to prove it, took Atkinson for a walk outside. During their walk, amongst many examples of rounded rectangles, they came across a no-parking sign with rounded corners, and Atkinson was convinced. He said he’d give the problem some thought.

The next day Atkinson came back and demoed blazingly fast rounded rectangles being drawn on the screen. And today, 30 years later, if you look around any computer screen, you’ll see rounded rectangles everywhere.

OK…and so what?

In reality, neither time in milliseconds nor rounded rectangles on their own are going to have a huge impact on any given product. My friend wrote his funky SQL and converted the times as needed. And whether a dialog box has rounded or square corners, it doesn’t directly change the functionality of an application. But each does have a small impact on the product by increasing or decreasing the burden on the user to extract value from the product.

Now imagine corporate cultures where  each of these examples are applied repeatedly for a given product. i.e. one product is consistently designed for the machine. Another product is consistently designed for the human. What would be the end result?

In both you’d have a functional product. With the former, you’d have a product with a lot of rough edges and a lot of knowledge needed by the user to be effective with the product. With the latter, you’d have a product that is distinctly different from it’s competitors and a pleasure to use.

User’s wouldn’t always be able to enumerate why the latter was great, but they’d certainly tell you which one they wanted to use.

And why would that be the case? Because the designers of the latter application paid really close attention to all the fine details. It’s about a culture of craftsmanship. The rounded rectangles story changed Bill Atkinson’s view of what was needed, and also what could be done with graphics on the Mac. It’s no surprise he wrote MacPaint (a killer app for the Mac) a few years later.

Now, getting back to the two divergent applications. Which application would you want to use? Which application does your company usually build? Why?

Saeed

Tweet this: Simplicity and Elegance Require Deep Attention to Detail – http://wp.me/pXBON-2Wh – #prodmgmt #design #innovation

Related posts:

1. The value of simplicity
2. Worth Repeating: The Value of Simplicity
3. The Need for Elegance in Product Design
4. What's the deal with Personas?

by Saeed Khan

If you’ve read anything about Blackberry maker Research in Motion (RIM) lately, it’s likely that the news has not been good.

Whether it was the underwhelming response to their Playbook tablet, the abruptly ended BBC interview by Co-CEO Mike Lazaridis, or the recent drops in RIM’s stock price, negative news seems to have a death grip on the company.

People are looking at the growth of iOS (Apple) and Android based phones, with RIM dropping to a distant 3rd in market share.

But in all of this doom and gloom, it’s too early to count RIM out,  and there are real lessons to learn about dealing with shifting markets and new competition against established players.

First, let me say that while I’m a big fan of RIM for a number of reasons, I don’t have any financial stake in RIM.  Second, I don’t have any “inside” information that I’m sharing. This post is an outside-in view of RIM, trying to look past all the noise in the news channels, and analyse the situation from a Product Manager’s viewpoint.

The market has changed

I remember when the first colour Blackberry’s were introduced. Wow. Nice screens and they got rid of the thumbwheel and replaced it with the trackball, which later became a small trackpad.  Those seemed like big changes for RIM.  But to state the obvious, Apple completely upended the game with smart phones, and for a while, RIM seems to have been caught snoozing.

RIM’s initial forays into more “iPhone”-like touchscreen phones were the Storm and the Torch. Neither met with major success. They were simply me-too products when compared to the iPhone, and poor ones at that.

But RIM is not simply a handset company. RIM provides infrastructure to both carriers and enterprises. For carriers, RIM provides billing services, secure and efficient email and data transmission, and device management services. For enterprises, RIM provides the Blackberry Enterprise Server (BES) for provisioning and managing the devices.

These are clear differentiators when compared to the iPhone or Android devices. They are why both carriers and enterprise IT favour the RIM devices. And these are the likely reasons why RIM did not react more quickly to the threat of consumer-oriented touch-based smart phones like the iPhone.

Battleships turn slowly

But RIM is changing, and while it may not be clear to all, the Playbook tablet is key to RIM’s transformation.

Sure, people are complaining about the Playbook, the lack of apps and email integration etc. But RIM is not in the tablet business. They’ll definitely sell their share of tablets, though nowhere close to what Apple with sell.

The reason that the Playbook is important is because it, and more specifically the QNX operating system it runs will be the foundation of the next generation of Blackberrys. This fact was announced last fall, though it seems little attention has been paid to it by the broader press.

In short, the Playbook is the lab, before the new Blackberry factory gets into gear. This is a critical point to keep in mind.  For established companies like RIM, change will rarely happen rapidly, given the technology, systems, processes, contracts and other business issues to deal with.

But then, are RIM’s customers demanding change overnight? How fast can RIM’s customers, mostly enterprises, consume any change? And at what cost? Would they trade off speed of delivery vs. stability, security and management? And if so, why?

These are some of the important question to ask when addressing significant market shifts.  And once you have the answers, a strategy can be put into place to manage the change.

The road ahead

There are still many challenges ahead for RIM.

• They definitely need to get their new QNX based Blackberrys out soon, ideally in 2011 and NOT 2012.
• They need to create, educate and grow a thriving 3rd party development community.
• They need to acquire (or seriously partner with) mobile application or cloud service companies to provide differentiated capabilities for enterprise and business users
• They need to provide incentives to existing customers who move to the new QNX Blackberrys vs. losing them to iPhone/Android handsets.
• They need to show the market and investors that they are still an innovative company that can deliver rock solid products.

While the market will give Apple slack for things like AntennaGate, or taking a very long time to ship a white iPhone, it’s unlikely the same grace will be given to RIM. Let’s face it, Jim Balsillie is no Steve Jobs.

So, even though the market for smart phones has shifted, and forced RIM into a defensive position, it’s clear they have a plan and are executing on it. Given the storms RIM has weathered in the past, if history is any indicator, RIM will make the shift from old to new platform, despite the doom and gloom predicted by many pundits. It may never be as sexy as Apple, but then who is? But in the end, there is nothing wrong with a profitable, $20 Billion dollar company.

Saeed

Tweet this: Addressing Market Shifts, or Why RIM is not down and out just yet. http://wp.me/pXBON-2vB #prodmgmt #strategy #innovation

Related posts:

1. iPhone vs. iPod Touch
2. Partnering for Strategic Breakthroughs
3. How to dominate your competition – learn from Apple
4. Honey, I bought the Phone. Confessions from the Cambridge Apple Store.

by Saeed Khan

Last week, I discussed Go-to-Market and Organizational Metrics. This week I’m going to discuss Product metrics. And while the title of this post sounds somewhat repetitive, as seen in previous articles Product metrics are simply one category that need to be tracked as part of a holistic view of “the product”.

BTW, if you haven’t read the first article in this series, you can read it here: A Model and Metrics for Tracking Product Success.

As mentioned in that article, when thinking about metrics, most people think about the Product first, and for obvious reasons. It’s the focus of the business, and is the most visible and tangible outcome of everyone’s efforts.

And when thinking about Product metrics, the mind most likely turns to the common metrics related to bugs, escalations, etc.  All of these are useful, but not as primary measures for product success. Product success needs to be viewed from a higher perspective.

I look at the following list as key areas when tracking product success:

• Strategy
• Roadmap
• Capabilities
• Gaps
• Quality

Keeping abreast of these categories will provide a clear picture of the state of the product over time.

Strategy

Strategy can be a nebulous topic. And while defining product strategy is beyond the scope of this post, there are questions that can be asked to help identify whether the strategy is a good one.

Here are a few of them.

• Is the overall strategy to be market leader or fast follower or something else?
• Is there even a clear product strategy at all?
• Is it to sell into an existing customer base, or to acquire new customers?
• Is the product targeting a specific niche or problem space?
• Have changing market conditions (e.g. new entrants in the market, price pressures, regulatory changes, market awareness etc.) impacted the effectiveness of the strategy?
• What threats (if any) are known that may impact the strategy?

There are likely many other questions that should be asked, but the overall assessment of them will give an measure of how relevant and potentially effective the strategy is.

Roadmap

Ah yes, everyone’s favourite topic.  The roadmap ties directly into the product strategy. In short the roadmap is an articulation of that strategy.  A well defined strategy enables a clear roadmap.  And with a poorly defined strategy, the rule “garbage in, garbage out” takes effect. Regardless, it’s important to think through the roadmap, using the overall strategy as a guide, and assess how well that plan fit in with overall business goals and directions.

Capabilities

This is an honest assessment of what the product can do. Where are the strengths and weaknesses, and where the risks lie in those capabilities. Are there functional areas where competitors consistently win over your product or that customers/prospects say are missing?

Gaps

Gaps are called out explicitly because these are areas  that need specific additional investment. And the question really is how much investment, in what time frame, and what is the resultant business impact of making those changes? One word of caution when thinking about product gaps. It’s very easy to fixate on these above other product aspects, such as product strengths. How often have we all heard someone say, “I must have this feature.” or “Without this new feature, we won’t be able to compete.” In how many cases are those statements 100% true?

Monitor and manage product gaps, but view them as one area of focus that doesn’t disproportionately outweigh all others.

Quality

This is something that most product managers are familiar with, having sat in on bug triage sessions, been involved in customer case escalations, or simply hearing about quality issues first hand in customer conversation. Nothing irritates customers more than poor quality products, particularly ones they’ve paid for. And they won’t be shy about telling you about those problems.

This is one category where a deep analytic assessment is possible, and that should factor into how quality is measured. i.e. consider measures such as new customer reported bugs,  bugs addressed, severity of bugs reported, # of customers reporting bugs etc. All of these can be looked at over time to see if the problems are increasing or decreasing. Based on this assessment, additional investigation into specific problem areas can be conducted.

Putting it all together

As I did for other posts in this series, the following is an example of how these categories can be rendered for easy interpretation.

Other categories

Depending on the product, market and strategy, there may be other product categories to consider, so look at your product and objectives and decide what is important to measure and track.

Overall, the goal of these metrics should be to provide a holistic, yet easy to understand view of important product and business areas, with potential problems or shortcomings clearly visible for discussion and further analysis.

Saeed

Tweet this: @saeedwkhan Product related metrics for Product success http://wp.me/pXBON-2uj #prodmgmt #innovation

Related posts:

1. A Model and Metrics for Tracking Product Success
2. Defining Business-Oriented Metrics for Tracking Product Success
3. Go-to-Market and Organizational Metrics for Product Success
4. Product Management Metrics (part 2a)

by Saeed Khan

Last week I wrote a post called The Need for Elegance in Product Design. In it I said that calling something elegant is high praise, and although elegance is not a requirement for product success, those that are elegant, that have a “Wow” factor to them easily stand up above their competitors.

A reader, Rohan, left a comment that makes a good point. He wrote (edited for brevity):

Saeed, as much as I love elegance myself, I’m not at all sure that most people care about it.

Given the commercial success of so much that is inelegant, I don’t think you can claim that there is a “need for elegance in product design” without backing it up with some hard data. Certainly it’s a desirable thing to some potential customers, but maybe not all that many. I conclude that elegance is a “feature”, complete with price tag.

First, let me restate the definition of elegance I used in the original post.

gracefully concise and simple; admirably succinct

As I said in my original post:

Being elegant is NOT a hard requirement to have a successful product. But think of the products you admire, whether physical or electronic, that rise well above the crowd. I’m sure most of them can be described as elegant.

The focus here is on market leaders, becoming one and sustaining that lead, and not simply on creating a product that meets some market success.

Disruption is everywhere

The reason that elegance — smart, intuitive design — will grow in importance is because other barriers and differentiators are undergoing significant disruption. From funding to prototyping to manufacturing to distribution to marketing to retail, all of these areas are changing and making it easier for new, small and fast companies to enter markets.

Kickstarter.com is a relatively new site to help new projects and businesses get both exposure and funding using crowdsourcing. You no longer need to go to the bank or find angel investors or as friends/family for initial funds.

The advent of 3D printing and outsourced prototyping services means that anyone who can use (or learn to use) 3D modeling software can design a product and get a physical 3D instance of it for very low cost in a very short timeframe. And this technology can produce stunningly complex objects.

Sites like Shapeways make the manufacturing process dead easy for low volumes. And for anyone with higher volume needs, there are of course more traditional manufacturing means.

As for marketing and retail, the Internet has made the process much easier for smaller companies to get visibility.  They have many options, particularly for retail, from sites like EBay, Amazon and Etsy to a myriad of smaller sites, and of course it takes less than 1 day to actually set up a full web presence to sell products online.

How can companies create sustainable differentiation?

This disruption makes it easier for companies to create, market and sell their goods to a wide audience. But it also means that it is that much easier for others to copy their ideas in record time. Look at how quickly companies have announced and built tablets to compete with the iPad. This would not have been possible 20 years ago.

Remember the $100 laptop project? How about the $10 tablet project? This is not to say that these are all elegant products, but the fact is that it has never been easier to quickly get inexpensive derivative products to market.

So how can companies differentiate and sustain product leadership?

There are still a few areas that are not yet disrupted or not yet commoditized. One of them is design: good, thoughtful, elegant design.

And design goes beyond just the look of the product. It involves how the product functions, how it is built, how it is delivered and yes, how much it costs.  The design process can (and should!) identify ways to drive DOWN costs, and therefore prices of products.

Elegant design takes all of these into account, and delivers differentiation on MANY fronts. These are not things that can easily be duplicated.  But when they are, and they will be as markets and competitors are not static, the challenge is there for all parties to move forward, become more efficient, improve the designs,  and create new, elegant  products to lead the market.

Given the pace of change we are seeing, driven primarily by technology, it’s the human aspect, thinking and creatively solving problems, that will drive innovation and product leadership.

Saeed

Tweet this: @onpm Why Disruption is Driving the Need for Elegant Products http://wp.me/pXBON-2f2 #innovation #prodmgmt #leadership

Related posts:

1. The Need for Elegance in Product Design
2. Bill Campbell says, It all starts with great products!
3. Ask OnPM – How to deal with acquired products
4. Usability as a strategic weapon. Lessons from Wesabe’s founder

by Saeed Khan

When I was in university, my major was Physics, and for whatever crazy reason I took a number of Computer Science and Applied Math courses as electives. OK, I admit it, I was bit of  a “mathochist”.

Needless to say, I spent a lot of time with classmates solving math/physics problems. Often we’d make our way into the one of the graduate student lounges, which had nice sofas and floor to ceiling chalkboards — yes, I’m that old — and we’d work away.

One of the most satisfying aspects of these exercises would be when one of us would find an “elegant” solution to a problem. Usually it wasn’t me who found these solutions , but I recall once, in my final year of university as we were studying for exams, my friend Richard and I standing quietly, looking at what we’d written on the chalkboard, admiring the elegance of the solution we had found.

And while that sounds incredibly geeky, I’m sure all of us have had similar moments in our lives after a particularly proud accomplishment — whether it was something we wrote or created or built.

Now if you look up “elegant” in the dictionary, one of the definitions is:

gracefully concise and simple; admirably succinct

What a wonderful picture that evokes. Notice it doesn’t just say “concise” or “simple” or “succinct”, but “gracefully concise” and “admirably succinct”.

To call something elegant is a wonderful compliment. It conveys something deep about that object.  It implies that people gave a lot of thought about that object, what it should look like and how it should function.

Elegance doesn’t happen by chance, and it’s hard to describe what makes something elegant, but once you see it, you recognize it immediately.

Take a look at this video.  Many of these products are quite elegant. I showed this video to my children and I could tell from their reaction, they saw the beauty I saw.

Listen carefully around the 5:00 mark when the narrator talks about the design process.

Could you see yourself buying some of these products? I could, and that’s just after seeing them for a few minutes on a YouTube video!

So the question to ask yourself is, can your own design and development process create anything that could be called elegant by customers or prospects? Could a short video of your product have a similar impact on them?

If not, why not and what needs to change to enable it?

If yes, is the elegance the result of an intentional aspect of your process? How could you improve it?

Being elegant is NOT a hard requirement to have a successful product. But think of the products you admire, whether physical or electronic, that rise well above the crowd. I’m sure most of them can be described as elegant.

Saeed

Tweet this: New Post – The Need for Elegance in Product Design – http://wp.me/pXBON-2cY #prodmgmt #design #ux

Related posts:

1. Why Disruption is Driving the Need for Elegant Products
2. Simplicity and Elegance Require Deep Attention to Detail
3. Guest Post: Do Product Managers just take credit for great UX design?
4. The Importance of Perspective

NOTE: This post was originally published in January of 2009.  It’s interesting to note that almost 2 years later, Aptera has yet to ship any vehicles to customers, and is still is working out a lot of issues with the unique design of their vehicle.

I have nothing against Aptera, but their example goes to show that while a single revolutionary feature — i.e. a claim of 300 miles per gallon fuel consumption — can get you headlines, it takes a LOT more than that to get a product out the door. For those interested in news about the Aptera, this site has a good collection of posts and details some of the hurdles Aptera has encountered.

——–

I’ve written before about frames of reference. That’s the term I use (borrowed from physics) for how we can perceive situations around us differently from others due to differences in context. When building products, our frame of reference when defining priorities is based on previous experience, our objectives and our understanding of (or lack thereof) the target market or user who will ultimately use the product. Lacking any real understanding of the target audience, we default to our own needs and assume (or hope) they apply to others.

In an episode of the cartoon series The Simpsons, Homer Simpson’s long lost half-brother Herbert is the owner of a successful car company. He asks Homer to design the company’s next car; a car for the average family, just like the Simpsons. Homer asks for a number of features on the car:

• A giant sized drink holder for those “super-slurpers at the Kwik-E-Mart”
• Tail fins, bubble domes and shag carpeting because “they never go out of style!”
• Multiple horns that all play ‘La Cucaracha’ because “you can never find a horn when you’re mad”
• A separate soundproof bubble “for the kids with optional restraints and muzzles”
• With an engine “powerful like a gorilla, yet soft and yielding like a Nerf ball”

Think this kind of thing only happens in cartoons? While I haven’t seen anything as truly hideous as this car in real life, I recently came across an example of a car that was built by engineers, and apparently for engineers. It’s called the Aptera, and it is an actual electric and hybrid vehicle that is meant for production, with a list price of about $30,000.

The shape of the Aptera is designed to minimize wind resistance. In fact, if you visit their website, you’ll get a brief lesson in aerodynamics and drag. Do I need to know that as a car buyer?

Note the doors are gull-wing in design, but the door windows are fixed. You can’t open them. So much for using any drive through service such as a bank machine or fast food restaurant or toll booth!  NOTE: This issue has since been addressed and new versions do in fact have roll down windows.

And looking at it from the side, imagine the huge blind spots the driver will have both on the passenger as well as driver side. Note that none of the photos above show external rear-view mirrors on the car, but apparently they have added those to the vehicle. There is also a rear view camera system that is meant to minimize the blind spots, but that seems like a workaround IMHO. They’ve optimized for aerodynamics and now need to add features to address usability problems they’ve created.

Now, this vehicle isn’t all bad. It is claimed that the hybrid model will get 300 miles per gallon of gas. Amazing achievement if it’s true, though with crude oil currently trading at about $50 $80 per barrel, extreme fuel efficiency isn’t at the top of everyone’s list right now.

Second it has a number of interior features including:

• 2 cup holders (the car seats two people)
• smart phone connectivity
• driver and passenger airbags
• side impact beams
• solar assisted climate control

So, it’s not as hideous as the Homer — no horns playing ‘La Cucaracha’ — but it’s an example of what can happen when products are designed with the wrong frame of reference. 300 MPG is great, but you know what, I’d take 150 or even 100 MPG and a lot more usability.

Aptera, if you are listening — change is a process. Your intentions are great, but there are a lot of changes you’re imposing on your users. The path to success is helping address our problems without requiring us to completely change our frame of reference.

Saeed

Related posts:

1. When form doesn't follow function
2. Worth Repeating: Devil’s Dictionary for High Tech
3. Worth Repeating: Innovation Lessons from Intuit’s Scott Cook
4. Worth Repeating: How to be a GREAT Product Manager