Archive for the ‘Product Management’ Category

« Older Entries

Product Design – Flexible is Fat and Omnipotent is Impotent

Monday, April 12th, 2010

I’m a huge fan of Marty Cagan’s book and blog.  His most recent post on “The Domesticated Computer” got me thinking about how and why so many products not only take too long to develop but fall so short of user expectations.

I’m convinced that we have a nasty habit of attempting to launch products in all phases of development, and especially in the initial product launch, that simply do too much.  While we’ve all heard of the Pareto Principle, it seems that we just don’t apply it to our product development efforts.  Far too often we find ourselves in product discussions that look more like congressional pork barrel politics.  Features are negotiated based largely on executive pet projects than structured methodologies like Moore’s Whole Product Concept.

As Marty C points out, the personal computer, with all of its flexibility, is still difficult to use in many respects.  In the mid 90s I ran a project at Motorola that took computer keyboards off the manufacturing floor in favor of a yes/no device.  While the activities of the manufacturing line stayed largely the same, productivity increased.   Users indicated that the system was simply easier to use.  Nothing changed in terms of keystrokes – only one was still needed.  But less was better and faster.  More was fat and impotent.

Contrast the PC with purpose built systems like the iPhone, iPod, iPad, Kindle, etc.  The latter devices all have relatively limited primary input mechanisms.  Sure some of them have keyboards – but they aren’t the primary means of interaction.  More importantly these systems are designed to accomplish a subset of tasks as compared to the computer.  This limitation in functionality allows for better interaction characteristics and less user confusion.  It’s a lot easier to design easy to use systems if the system being designed only needs to flip pages and perform searches or scroll through and play music.  As my partner Mike Fisher points out, there are probably reasons why kitchen appliances still largely do one thing rather than a combined fridge/toaster/fryer/baker/washer.

But what lesson does this have for us in designing web applications?  Less functionality leads to less confusion, easier interaction development and faster time to market.  Develop the 20% of functionality that will deliver 80% of your revenue and refine it until its perfect using multivariate (or simpler A/B) testing.  Speed and focus is so much more important in web based properties, especially in early releases, than breadth and depth of functionality.  The folks at 37 Signals say that you can always do less.   Our point is not only that you can do less, but that you SHOULD do less.  Less is faster.  Less will allow you to get the core functionality out and perfected quickly.  Less wins.

Tags: , , ,
Posted in Product Management | 2 Comments »

How to Deal With Unintended Consequences

Saturday, November 7th, 2009

Having just read Levitt and Dubner’s SuperFreakenomics as well as Tenner’s Why Things Bite Back, I’ve been thinking lately about unintended consequences, sometimes referred to as a “law of unintended consequences”. As defined by Rob Norton, it is “that actions of people – and especially of government – always have effects that are unanticipated or unintended.”  Norton sites the reference to unintended consequences to luminary economist and social scientist such as Adam Smith, in his “invisible hand” that self regulates markets, and John Locke, in his campaign against the 1692 legislation for limiting the maximum rate of interest that could be charged.

In Tenner’s book he covers a variety of topics including environmental, medical, and technology advances that have caused unintentionally problems. He uses the term “revenge” as in these advances have taken revenge on those who initiated them. What interested me was not the “revenge” but rather just our inability to predict accurately the outcome of our actions. All of the examples appear to be complex systems, meaning that the exhibit behavior not obvious from the properties of their individual parts. As much as we understand about the human body there is at least an equal amount that we do not understand. The same goes for our environment. Argue with me if you will but when the accuracy of a 7-day weather forecast is less than 50% (using the meteorologist standard of temp predictions within 3 degrees as accurate) or 85% accurate for precipitation 1 day out, it is hard believe that we have a great understanding of the earth’s climate and weather systems. Perhaps you can make a case that on a micro-scale we’re inept but from a macro-perspective we know what we are talking about.

When we add to our Software as a Service or Web 2.0 sites our human customers then I believe our systems start to take on attributes of complex systems. If we could accurately predict the human-computer interaction of our system then we would find all the bugs in our next release in QA. Unfortunately time and time again we learn of bugs or unintended consequences such as a huge drop off rate in sign-ups only after the release after it goes live and real people start interacting with it.

Why we fail at predicting human behavior or weather patterns or any number of other subjects is too broad for a post. However, with the knowledge that we will fail, we can take actions to minimize the impact of the results. The way to achieve this is through A/B testing or split-testing. If you approach changes in your releases as if you’re just as likely to reduce some desired behavior as you are to improve it, you’ll want to have a way to test the results in the real world before committing to them. In our practice we often tell clients that they should have an A/B testing framework or a wire-on/wire-off framework for a variety of reasons including risk mitigation for new features. In today’s world where there are free services that can help with this such as Google’s website optimizer, here is a great case study of how to use it, there really is no excuse for not having this ability within your site or service.

Tags: , , ,
Posted in Product Management | No Comments »

Initiatives That Kill

Wednesday, October 14th, 2009

In a recent post Marty talked about false urgency being terrible for the performance, morale, and well being of a company. I’d like to add to this the wasted time, energy, and money on “initiatives”. Similar to how creating a false sense of urgency leaves the employees unmotivated and ridiculing the project, initiatives that do not support the mission of the company produce the same effect.

As an example of what I mean by “initiative” let me relate a project that was undertaken recently by a large corporation. In a cost reduction effort someone was assigned to walk around and patrol the office area for plugged in electronics and appliances. In my mind this is just ludicrous. First, the company has hired people they trust to build their product or systems.  If the company wants to initiate a cost reduction plan to reduce the electric bill, send a note out to the employees asking for their help. A much better approach is to demonstrate that you trust that they will help with reducing costs. Second, my bet is that the time wasted by this person patrolling the area, some manager monitoring and reviewing the patrols, and the other employees making fun of this cost the company more than it was able to reduce. And third, the company should weigh the cost of possibly having to replace a single great employee against the cost savings of such initiatives.

This example provided seems to be pushing to an extreme the silliness boundary of what someone can dream up under the guise of cost reduction but fails to interpret the further ramifications. Looking at just the balance sheet or income statement fails to take into account the wasted time by employees and aggravation over such imposed bureaucracy. Another clear sign to me of a company that is focused on the wrong things is when purchases must be performed through a centralized acquisitions organization. I understand and agree that there is no need for every department to negotiate a cell phone plan but when the IT department must involve a non-technical purchasing agent to whom they have to justify the purchase and allow that person to negotiate with the vendor, things have gone overboard. There is no reason that managers shouldn’t be given authorization for purchases up to various amounts and escalations going, not outside of their department, but just to their boss.

If you’re in an organization that has implemented these initiatives you should take the true pulse of the organization and see if you don’t come to the same conclusion. Working on these bureaucratic initiatives are likely costing you more in productivity, creativity, and deliverables than whatever amount you are saving.

Tags: ,
Posted in Product Management | No Comments »

Perception is Reality

Sunday, August 16th, 2009

We’ve all heard that saying “perception is reality” but do we really believe it applies to us? We all probably think we’re competent at our jobs but being so is only half the journey. We need to demonstrate that competency to our peers, employees, bosses, and customers in order for it to matter.

In good counseling sessions we should receive some praise for what we’ve done well and some feedback for areas that we need to improve. My advice to people receiving feedback is first determine if it is factual. Do you really write poor quality code? Are you actually tough to work with? If you believe the feedback is not factually correct, don’t become defensive and try to refute it because the blame is still yours! Even if the facts are incorrect but your peers, boss, or customers perceive them to be correct, you own this perception.

People usually hate to hear this and think they should just have to focus on their skills and everything will work out but the reality is that you need to own people’s perception of you. The same goes for customers. You cannot just focus on building a good product and assume customers will flock to you. You have to own your customers perceptions, which means you have to consider not only the quality of the product but how you introduce the product, how you roll out the code, how you perform maintenance on it. All of these ultimately result in your customer’s perception of the product, not just the number of bugs.

Tags: , ,
Posted in Product Management | 1 Comment »

To Succeed Big, Think Small

Wednesday, July 29th, 2009

I, like a lot of you, read lots of blogs and articles each week, some of my favorites include Joel on Software, Coding Horror, High Scalability, Seth Godin, and Tim Ferriss. I also read just about cover to cover the IEEE publications that I receive. I use a variety of methods to keep track of the ones that I like so that I can find them easily when I want to reference them. Two of my favorite tools to do this with are Evernote, where you can clip web pages with tags into your notebook, and ShareThis, where I can drop something in my sharebox and send it to someone at the same time.

I was having a discussion the other day about small services as business opportunities and recalled several threads that seemed to be tangentially related. I parsed through my clipped, starred, and shared items and found these pearls. Whether you are already part of a start-up or considering one here are some ideas that you might consider.

And since one of the technical editors of our book has pounded into my brain the demand to “explain how this relates to scalability”, let me explain. If you’ve read a few of our posts you know that we believe that scalability is about more than technology, in fact if done correctly it’s technology agnostic, but depends greatly on people, process, and architecture. This starts even before the business is founded. The right business plan that balances people and investment with real revenue earning products is critical to scaling. If your cost are too high to service a given number of customers you are losing money. Now you can argue that you’ll get efficiency of scale at some point but you need to survive long enough for that to occur. Without further ado, on to our amalgamation of advice:

Seth Godin says the way to make money on the Internet is by connecting people with what they need. He gives examples that include the following as well as many more:

Connect advertisers to people who want to be advertised to.
Connect job hunters with jobs.
Connect information seekers with information.
Connect teams to each other.

Kevin Kelly says the solution for inventors who are up against the giant aggregators like Amazon is to find 1,000 “true fans”.  If each one is willing to pay $100 each year for something that you invent or service that you provide you can make a great living. This might be four CDs that you produce each year. For those organizations comprised of more than just a solo artist, Kelly states that an increase in fans is necessary but is linearly proportional to the increase in the team size.  He continues that because of the network effect (Metcalfe’s Law) it is likely that the value of the your fans increases proportionally to the square of the number of fans, which means the number of true fans does not have to double to support a duet.

Paul Buchheit, the 23rd employee at Google and creator of Gmail says stick with it, overnight success takes a long time.  They started Gmail in 2001, launched it in 2004 and 7 years later is seen as a huge success with annual growth rates of 40%.

Matt from 37Signals advises to keep your day job and work on your start-up on the side. Even though he capitulates that starting a business does require plenty of time and effort, quitting puts a shot clock on your idea. When coupled with Buchheit’s notion of success is a measure of endurance not speed, this seems like sound advice when possible. For those already under the pressure of the shot clock just remember that is monetization is king and survival is a competitive advantage.

So far in our bucket of advice we have 1) connect people with what they need, 2) find 1,000 fans to support your dream, and 3) don’t jump in until you are able to stick with it for the long haul. What I can add to this is Think Small. Throw away the fifty page business plan that requires $25 million of investment to sustain a profitless company for seven years. Instead think of a single service that people or businesses need.

For Internet companies, there are dozens of services that they need as part of their product offering but only as a small part.  Therefore they either don’t have the expertise or they can’t dedicate the resources to build it well. An example of this is search. Lots of websites need search functionality but few are going to build it themselves when there is a site search tool built by experts available.

Services that come to mind and that either need to be done or need to be done better are contextual classification, yield optimization, micro-payments, recommendations, abstracted scaling, and application monitoring. Go give it a shot and think about scaling from day one of your business.

Tags: , ,
Posted in Product Management | No Comments »

« Older Entries