The Hungry Ant

One aspect of product development that is really important is to find partners or clients that are willing to pay for your final product. Without this level of feedback it is difficult to get a sense of whether you are going in the right direction. Another factor that is extremely important is to get the pricing right. Price it too high and you may get some clients but maybe not enough to sustain the business, too low and it won’t cover your costs. By seeking out potential clients early in the process it can drastically change the direction you may take and can give you invaluable information about pricing.

Add to this a regular feedback loop with end users and you have a much better chance of arriving with a product that people will love and will pay for.

One of the big changes that has happened since I started my new role is the addition of interaction designers (3 in fact!!) into the company. It was interesting trying to explain to the business what they actually do, but they thankfully took my word for it. It turns out that Sardinia has just started an Interaction Design Masters full of new talent wanting to work (it is funny how things work out like that). So I am very happy that we got to pick some of the top students.

As a product manager, the interaction designer backs me up in trying to think about the user and also frees me up to handle the great juggling act between development, design and business. They are necessary to create great products.

It is also amazing how after 4 months the interaction designers are seen as important and needed members of the group. Very satisfying.

I learnt a lesson the other day. I am involved in 3 projects at the moment, 2 of which we started from scratch and were started with product opportunity assessments. The third project had already been running when I joined. I mistakenly made an assumption that the questions in the assessment were asked and the project had moved forward from there. The other day, once I noticed a few issues come up, I organised a risks meeting and out popped some fundamental problems that I would have looked to identify (and hopefully resolved) much earlier in the process. My mistake was too think that what seems obvious to a product manager (who is thinking in a certain perspective) is obvious to everyone (who actually may have different perspectives).

We are currently developing a new product and are busy analysing all the data we have gathered from interviews and statistical data to create our personas.

My aim as a product owner (in my agile hat) is to arrive at a product backlog that has user stories that are fine grained enough that we can estimate how long things will take. The problem is that often it is difficult to get to the this breakdown as we lack information.

A natural fallout of creating personas is that you often have a set of large stories that describe how a user will use the product. This is agile speak is called an Epic and can then be broken down into smaller chunks for estimating.

Storyboarding is a powerful, tried and tested method of thinking about epics and I like to work with the interaction designers to visualise the Epics. This way we are also thinking about the interface and the interaction which is the next phase for the interaction designers anyway.

The storyboards are quick sketches that I will then breakdown into a set of user stories that can be estimated and hence be actually developed.

So an epic maybe something like:

“George wants to choose where to go on holiday as he has two weeks off at christmas”

which may breakdown to

“George wants to search for a beach holiday because he needs some sun and sand”

“George want to go from the 12th to the 30th of June because that is when his holidays are”

…

I will also add Epics to the product backlog but at a lower priority while they need to be expanded with detail.

I place a lot of importance on retrospectives, especially at project close. All projects have good points and bad points and it is important to learn from them so that the next project benefits. Retrospectives also provide the team an official closure and isolate problems to the scope of the project.

Project management processes like Prince 2 find this so important that it is a key phase for all projects.

If you are thinking of having an end of project retrospective, I recommend reading Agile Retrospectives. It provides a list of patterns for running retrospectives, whether at the end of the project or  sprint/epic. My particular favourite is the “Timeline” method for analysing a project. I have had great success with this as it provides an obvious and simple way to gather information about the project and it helps people focus on what actually happened.

Here are some tips for running a retrospective:

• The key skill is to manage the behaviour of the group and to keep the group to analysing the facts and not starting a blaming session.

• Warm people up by starting with introductions or a game. Some people are louder than others, your job is to help everyone be heard, this helps their tongues loosen.

• Have house rules for behaviour during the retrospective, and see that people stick to them.

• Follow a structured approach to extract data, like using the “Timeline” technique. During this phase try to avoid analysing until the next phase. This part is hard as the group wants to talk about the most pressing issues straight away. Although common sense is required.

• As long as you know the group well, keep rolled up pieces of paper to throw at people (gently) if they start deviating from the rules. It seems to help lightens things up when it is needed.

• If there are any action points as part of the retrospective, make sure that they are documented and that someone in the group takes responsibility for each action with a deadline.

• Have a fixed time for the different sections of the retrospective.

• Make sure that you write up the retrospective within a couple of days and circulate while the points are still fresh in people minds.

• Take a digital camera for taking pictures of the timeline and all the materials like post-it notes and pens.

I am currently working on identifying new product areas that we could go into and have been using the product opportunity assessment as a basis for extracting all the current ideas we have into a form where we can decide which we should be working on.

As Marty says, it is the first question that is the most difficult and I think it is extremely important not to try to guess. Our assessments have already helped in giving us a much clearer sense where we should be putting our effort, but I think that we are lacking input from the potential customers. I strongly believe that before you start off on a new product you should speak to the potential users and understand if you are really solving a problem. If you are then the yes or no decision becomes a lot easier. If you are not then the risk of failure becomes a lot higher.

So off I go to find some users…

I wrote a paper for XP 2007 about my experiences at the BBC as a Senior Product Owner for their systems that power their messageboards, community sites (like H2G2, Filmnetwork and 606) and the new comments engine for their blogs. I was fortunate to be one of the first at the BBC to manage a Scrum project in 2003 for ActionNetwork. As I got the handle of managing scrum teams I moved to being a Product Owner/Manager and found my niche. It was great to see the agile process from that perspective and how agile and the product creation process combine.

The paper is here - Making the whole product agile - a product owners perspective