Category Archives: Usability

Guest Post: Web Product Management 101 for “Offline” Managers

NOTE: The following is a guest post from Thomas Fuchs-Martin. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.


You are an experienced software product manager and you are thinking about developing your first web product?

Great! This blog post is written especially for you!

Be aware: The fact that you are about to manage a web site really changes a lot in your product strategy and the management processes that you know from “offline” products. I have prepared a crash course for you – defining terms and phrases that you will need to understand as part of your web product management role:

CPC, PPC etc.
Due to the fact that there are many different kinds of business models that exist in the web world, a lot of abbreviations have become very common (I am not really sure if that is a good thing…), particularly when it comes to advertising!

Most common is PPC (Pay per Click) which describes a model where the advertiser is charged only when a user clicks on their ad. Google Adwords is the most well known example of this. The payment amount or CPC (Cost per Click) defines the price paid by the advertiser for each click.

Even if your business model will not be advertising-based, the day will come that you either want to advertise your product on other sites or that you want to implement some advertising model on your site. You will need to understand the common models to avoid (expensive) mistakes.

Emergency Deployment
A website has to be up and running all the time, and there can be numerous backend servers and database needed to do this. You’ll need to schedule regular maintenance time to handle patches and upgrades. But, if you encounter a large bug on your production site or the site is not working at all, you might need to interrupt the usual release cycle and schedule an emergency deploy to fix urgent problems. In the worst case you will have to adjust the timings of your product plan because of these events.

In “offline” product management you basically have to think about how to create a great user experience. In web product management you have to think about search engines, too. Unfortunately users and crawler bots don´t always have the same needs which makes SEO (search engine optimization) quite interesting. SEO is the process of improving traffic to your site from search engines.

Important: Do not get the idea that you can completely outsource this! The majority of modern internet business models are based on good SEO, and your product planning will be affected by SEO requirements right from the start!

Private Beta / Public Beta
That is possibly one of the biggest luxuries that you will have as a web product manager. You can launch your product while it is still in beta-state. You just put a “beta” label beside your logo and a feedback-button somewhere prominently on your page and see what happens – this is called “public beta”. If that is too crazy for you then you can password-protect your site and only share it with selected users – that is a “private beta”.

Very important: Get the idea out of your head that your product needs to be perfect before you can launch it! There are many minimalistic and half-backed products out there that are pretty successful. Early release beats perfectionism and the minimum viable product beats the over-featured product. Remember the early days of Twitter?

Well this has nothing to do with food! In the web a cookie is just a piece of data that will be saved at the client computer. A bunch of very common features rely on cookies such as online-shopping or login-sessions etc.  It’s important for you to know that features that rely on cookies can be very painful to test because the features can behave differently depending on the client´s configuration of browsers etc.

“See you at 2 am!”
Well, in theory you can release a new version of your web product at any time you want. But maybe you don´t want to risk downtime during the peak periods of the website. So for bigger releases and maintenance operations, the early morning might be the only time-frame of the day with low traffic …and you and your team are working hard while everybody else is sleeping! If your website has a huge amount of traffic you might even consider to launch at the weekends, because usually the traffic is lower during those times.

Browser Issues
Creating a useful user interface for websites is a hard job. In the offline world you “only” have to think about which operating system and screen resolutions your target customers have. In the web you also have to worry about different browser versions, browser security & privacy settings, pop-up blockers etc. It is almost impossible to create a complex website that will work with all browsers.

My recommendation: Focus on the most popular browsers and be minimalistic with the product features. The best way to figure out which browser your web product needs to support is to take a look in your web analytics. The diversity of browsers can vary significantly depending on the target group or target-country of your website. At minimum, your site should support Firefox, Internet Explorer (even the old IE 6 is still a common browser) and Chrome.

Web Analytics
You will have lots of information about the users of your product – for free! Google Analytics is the most common free web analytics tool that will provide interesting information about your users. For example: number of visits, pageviews, average time on page, country, browser version, screen resolution, bounce rate, top landing pages and much more. Get familiar with these analytics tools and identify the strong and weak points of your product!

Website Speed
Even in the age of high-speed internet connections you need to have a fast website! Not only do users like fast websites, search engines love them as well! Listen to what Matt Cutts from Google says about this:


I hope this crash course will be helpful for you to kick-start your web product manager career!

Thomas Fuchs-Martin is web product manager & SEO at the Spanish internet start-up – More articles about web product management can be found at his blog:


What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

  • 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
  • modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
  • For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
  • No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

  • Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
  • They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
  • These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
  • The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

  • There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
  • Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
  • Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
  • In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
  • There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Bill Campbell says, It all starts with great products!

Here’s a bit more from the Bill Campbell interview. I posted the first excerpt in “Bill Campbell says hire Product Management first!“.

Michael Moe is the interviewer. This exchange takes place about 4:20 into the video.billcampbell

Click the image above to open a window and view the full interview.

Michael Moe

So, what are the key metrics that you track when you’re working with a company. How do those metrics change as the company goes from being a startup, to an emerging company and as it gets larger? How rigourous are you with early stage companies?

Bill responds:

The rigour that goes into the first product is the most important thing. Everybody talks about great companies. Great companies start with great products.  You can’t make chicken salad out of you know what.

This is a truism if there ever was one. How many great startups can you think of that had mediocre products?  People may not know the company well, if at all, but they hear about a product and the product (good or bad) defines the company.

Bill continues:

I’m a big believer that you really track the progress of the product. I go back and talk about Mike Homer and a Product Marketing* like person. What are we doing to make sure we have something that we can ship and release? Get it out into the market place.

Tracking that one single thing — what can we do? who is it for? how do we guide it? Getting great product into the market place would the single most important thing.

That would be the number one metric that I’d judge and boy you’d go a long time in your company before you stopped doing that.

* Bill Campbell equates Product Marketing and Product Management earlier in the interview. See Bill Campbell says hire Product Management first! for details.

While not technically a “metric”, Bill again focuses on making sure the thing that is being built is being built for the right people. Making sure an identified target audience (and set of valued usage scenarios) are front and center during this early phase.

This answer also support’s Bill’s earlier statement that Product Management skills are key at the very earliest stages and should be hired in right at the start IF those skills are not strong amongst the founders.

One final note

What’s most interesting about this answer from Campbell is that he doesn’t say great companies start with great people. That’s what a lot of people would say, but it’s not true. Great people can build great products which lead to great companies, but there are many well known examples of companies started by experience or knowledgeable people (e.g. Cuil and Cassat) that have failed to live up to expectations.  Once a company builds a great product (or service) that people use, that drives company growth, and ideally makes the company a leader in it’s market segment, can a great company emerge.


UniFlame understands the value of customer experience

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

As a former technical writer, it’s always disappointing to see the sad state of virtually any kind of instruction manual or guide. These documents are literally afterthoughts, included I’m sure, simply because laws require assembly instructions or usage manuals.

In fact, too often with goods made in non-English speaking countries, you end with documents like this.

So, when I come across a set of instructions that is clear, unambiguous and easy to understand, it’s worth a positive shout out.

Recently, I bought a rather inexpensive charcoal grill. It looks like this grill to the right.

Nothing fancy. It’s not from a major name brand. But whomever created the assembly instructions knew what they were doing.

First, here is a shot of the COMPLETE assembly instructions


(click image to enlarge)

What’s great about this?

  • 8 simple panels, shown clearly on a 2 page spread
  • All parts clearly drawn and all assembly pieces identified and labeled with a letter
  • Minimal text to read and (mis)interpret – i.e. no tab A in slot B silliness

Yes, this particular photo shows the French instructions (it came with similar English instructions as well), but to be honest, the words could have been in any language and it wouldn’t have affected the clarity of the diagrams.

Here’s a close up look at one of the panels.


(click image to enlarge)

Note the letters associated with each of the 4 items in the diagram (bolt, 2 different washers, and a nut). Why is this important. Well take a look at the next two pictures.


(click image to enlarge)

Every item required for assembly is clearly packed and labeled (!!!) for easy access and identification. How easy? Notice that items B, G, K, F (used in the 2nd image above) are actually packaged together in the picture!

They could have just put everything into little plastic bags, tossed them into the box,  and let me figure out what was what, like many manufacturers do. But someone (I don’t know if Uniflame has Product Managers) decided that would not be acceptable. And on top of that, they included the tools I’d needed — screwdriver and small wrench — to put everything together.

But that’s not all. Whomever designed this little package of assembly parts, went one step further. Here’s the back of the package.


(click image to enlarge)

Yup. The letters are also printed on the back. So why is this important? Because the back is where someone assembling the barbecue is going to access the parts. Note the serrations in the cardboard.

Someone actually thought through this little detail and decided to print the part letters on the back and serrate it for easy access. And believe me, it saved me a lot of flipping the package over and back to figure out where the parts were that I needed.

Now, this is not a complicated grill to put together. It could be done with poor instructions, but it does say to me that someone at Uniflame actually cares about customer experience.  None of the points listed above are big things, nor are they costly to implement, but in most cases, companies bypass the extra effort altogether, looking at them as expenses and not as value-add.

And because UniFlame chose the latter, I’m telling all of you.  So, if any of you are  looking for a good charcoal grill, go and get this one from your local retailer. It’s about 1/2 the price of the comparable big name brand, and it works really well.

So, hats off to you Uniflame. You’ve impressed one product geek enough that he decided to let a lot of other people know.


The value of simplicity

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

We have 3 different types of food blenders in our house. They are pictured below. I’ve tried to show them roughly to scale with one another.


The first is a “traditional” blender with a base, a large 56 oz. (1.75 L) pitcher-style container and several speed settings for the blades.

The second is an immersion blender with a number of attachments for mixing, blending, chopping etc.

The third is known as the Magic Bullet blender. It has a small 16 oz.  (.45 L)  container for the contents being blended and a simple on/off mechanism for the blades.

While they all have benefits and are clearly different, guess which one gets the most use in our household? Given the title of this post, it should be pretty obvious.

Yes, it’s blender #3, the Magic Bullet. And why?

Simplicity in all aspects of usage. Most blending jobs are very simple quick tasks. e.g. making a smoothie, or blending some sauce or something similar. The usage scenario goes something like this:

  1. Place the contents to be blended into the blending  container
  2. Blend for 10-15 seconds (maybe 20 seconds in extreme cases)
  3. Pour the contents out of the container

There’s not much more than that. In *most* cases, the amounts are small (< 16 oz) so I don’t need the large blender which is both heavy and a bit of pain to clean. Also the immersion blender is pretty good for a lot of tasks, but I find it inefficient unless I truly have to immerse it into a pot or other container for “in place” blending.

In short, for the majority of my blending tasks, the Magic Bullet addresses the needs well. There is a lesson here for software and technology PMs, and I think you know what that is:

A simple solution that addresses a use case well is likely to be used often by your target audience.

Of course, most technology products do a lot more than a blender, but that doesn’t mean they have to be complex to use.


Innovation Lessons from Scott Cook

Here’s a great presentation Scott Cook (founder of Intuit)  gave back in 2005 on how Intuit develops new products. Needless to say, their approach is very problem oriented, customer research focused and with the goal of removing complexity from their solutions.

NOTE: Turn your sound on, as audio is embedded in the slides.



Usability is all in the details

If you haven’t checked it out, take a look at Cindy Alvarez’s blog: The Experience is the Product.

She recently posted a good article entitled:  Getting beyond beta: Measuring your audience breakdown.

Given the focus of her blog, the article describes some simple ways to analyse website traffic and conversion for a hypothetical ‘sock-matching service‘. Yes, that sock-matching service! 🙂

Cindy takes a straight forward approach at audience breakdown and provides some good advice and links to useful online tools to help address the problem.

While many product managers aren’t charged with specific focus on usability, when thinking about user loss and conversion ratios on the Web, there is a clear business case that can be made on the impacts (positive and negative) of good or bad usability respectively.

Great Post!