At Sky I was fortunate to really learn my trade well as product manager, working as I did with the best of the best across the organisation in finance, supply chain, procurement, strategy, marketing, research, technology and innovation. This gave me the skills to move into the small-to-medium enterprise environment and work autonomously without the huge teams and inevitable support a matrix organisation brings.

As a ‘doer’ for several years before I moved into a leadership role I knew I might struggle to completely let go of the day-to-day product owner tasks to entirely focus on line management and all that brings with it. This includes training, skillset building, KPI setting, championing the team across the organisation, representing the team and their work upwards, as well, of course, as being ultimately responsible for the entire output of the department.

In the end this transition happened organically as, initially I still had to be a product owner, as well as manage the team, as there were not enough product managers to cover the product suite. For me ‘managing’ as well as ‘doing’ worked well in the following ways:

• I was able to lead by example.  Day to day I showed the best practice approach to the task-oriented side of product management, as well as the communication elements of the role, taking them along to some of my internal and supplier meetings so they could see how best to lead the teams and be a product owner.
• I could understand the challenges the team encountered, where the current bottlenecks were and who best to approach first if trying to affect change in the business.
• Working on the overall product strategy alongside the CEO and board I was able to speak with the additional authority ground-level experience brings, rather than regurgitating what my team relayed to me.
• I knew what skillsets and abilities existed across the organisation from first-hand experience and could liaise with  contemporaries who headed up sales, support and technology to ensure future planning was based on realistic expectations.

 “I found current ground level knowledge in an organisation was crucial to the role of a product director”

Of course there are also negatives to this approach, but I truly believe that to ‘do’ and ‘manage’ is the nirvana of a product manager, as you get to continue to develop the skillset you’ve nurtured, whilst also getting to be a part of the management team and if you are really lucky, get to define the overall business strategy, as well as the product strategy.

If you want to ‘have it all’ I recommend you focus on:

Time management

Time management is absolutely crucial to the success of this approach. As well as managing your team’s expectations on how much time you can spend with them on their products, you need to consider your board’s expectations on the evolution of the product strategy, how much time and how often you will be able to present back to them and most importantly your own expectations on how often you will make the time to lift yourself up and out of the day-to-day grind. This is the only way you will get the full perspective you need to ensure your vision for your product suite evolves to plan, while assuring you are an effective leader.

Make sure to organise your day precisely, booking time in your calendar to do your line management admin, as well as your own product documentation and, whatever you do, please don’t be afraid to book ten or 15 minute meetings. I know that sounds unreasonable, but even if your office does not have a stand-up meeting area it’s worth creating one (standing by the printer or the drinks cooler). These are so incredibly effective and simple, you will find that people won’t chat and hang about if they have to stand throughout a meeting.

Lists, lists and more lists

• Write everything down, or even use a software as a service (SaaS) tool to help. I found Atlassian’s tool Jira a great way to log the KPIs and tasks I had assigned to my team. These tools also enable you to keep a track of your teams’ work load and report on their productivity.
• Make daily priority lists. Take five minutes every morning (or at the end of the day before) to list out your ‘to dos’, giving them a priority rating. For example have number ones (must do today) number twos (do if there’s time) and number threes (only consider if everything else is done, or can stay late).
• Be uber-organised in your note taking. Have a different note pad for your one-to-one meetings with your team, so you can refer back to these at each subsequent meeting if needs be, to track improvement. Have a different notepad for board/stakeholder meetings, product by product meetings and where necessary write up your notes, either as meeting minutes, or for your own use and reference.

Being a day-to-day doer meant that I really knew what each of the teams in the organisation were capable of and what challenges existed operationally, as well being immersed in the day to day with clients/customers/end users. I found that this was invaluable as I continued to build a product strategy and roadmap, as well as my team strategy. So if you are able to balance this out and manage your time well, your team as well as your product’s innovation will benefit as a result.

The post Moving From Product Management Into Product Strategy appeared first on MindTheProduct.

The roadmap design in ProdPad was such a radical departure from traditional roadmaps that we had no idea whether it would a) work and b) be accepted by users. If we spent lots of time building out a roadmap that then tanked, it was time and effort we couldn’t replace – a killer in a bootstrapped startup. So we went with the minimally viable feature or MVF approach.

We learnt a lot about the roadmap and this has fed into the recent updates to it – all for half a day’s original development.

Why use the MVF approach?

MVFs are particularly useful for products that have moved out of the MVP or minimally viable product stage. Once you reach that point, people start thinking in terms of fully realised features as they plan. These fully realised features will often take significant amount of resources and time to develop and deliver.

Using the MVF approach means you can test before you devote resources to further developing the feature. It allows you to learn as quickly as possible as cheaply as possible.

But will they even use it?

Even if you have half your users asking for a feature it doesn’t necessarily mean they will actually use the feature. What people say they will do is often radically different from what they actually do.

MVFs are a great way of continuing learning as quickly and cheaply as possible, even in mature products. Once a feature shows traction, then you need to double down on that feature and build it out to nurture that traction and realise the value the feature brings to the product. I’ve seen situations where a company didn’t focus effort on a MVF that had a lot of traction, which meant the company failed to capitalise on that traction to create a more valuable product.

When building a new feature, build as little as possible to prove that the users will actually use it.  Get their feedback on what works and what doesn’t, and put that to good use in building out your feature into a fully-fledged facet of your product.

The post The Minimally Viable Feature Approach appeared first on MindTheProduct.

While some may be interested in taking on that type of project (more security and potentially more money), personally, I’ve always pushed back on the client (ever so gently) and assured that the work can be done in a more flexible way, often without the typical five-day-grind commitment for either of us.

A few things to keep in mind when proposing an alternate work schedule:

1. What is the scope of the project?
As an experienced product manager, you should have a pretty good idea of how much time a project is actually going to take to complete. Think through some important questions when proposing more accurate time requirements. Would you need regular access to developers, designers, user experience or stakeholders? If so, the project might be a bit more time intensive as you have to work within other’s schedules and it might require you to be in the office more often. Will you be required to be in quite a few meetings as well? If so, that will take away from the time you’ll need to finish off specific deliverables.

When proposing a more flexible work week, just ensure that you’ve given yourself enough time to actually do the project well. So, take some time to understand the finer details of the project, and if you feel confident that you can deliver in a more flexible way – by all means – tell the client. They should respect you for your know-how and honesty.

2. Why does the organisation want you five days a week?
Is it just for ‘face-time’, aka Marissa Mayer’s resurrected Yahoo! HR policy, (I can say that because I used to work there ? Or, is the project actually going to take that much time? To answer this question, again, think through the requirements of the project.  If you, as an experienced product person, know there’s no reason to work full time to complete the project, find out more about the culture of the organisation.

Quite often, hiring managers seem to feel safer, more comfortable just knowing you’ll be there every day – but that doesn’t ensure the product will be done better/faster than if it was a few days a week. Remember, you’re the product expert and you should feel comfortable helping the client create a project that really will work for both of you.

Happy employer = happy product manager, meaning everyone wins. However, you may find that the culture really is one that requires you at a desk from 9am-6pm, five days a week. At that point, it’s your call. Personally, I’ve walked away from those contracts before.  If I wanted an inflexible work life, I never would’ve gone freelance!

3. How much time do you want to commit to the project?
This will depend on numerous things – your interest in the project; the amount of time that you have to dedicate; even your personal financial situation. Need more money and looking for a stable gig for a few months? Go for it – don’t fight the force! If you’re super interested in the project and think it’ll be a great experience – jump in!

The point is to remember that you are your own boss. There will be times when you/me/we need to take a project to pay the bills. That’s completely understandable. There will also be other times when you can politely tell them to take their five days and …well, you know…:)

The post Tips for managing time expectations in consulting appeared first on MindTheProduct.

The post Video: Proper product management in large organisations – do it with Jazz appeared first on MindTheProduct.

Please help us out, fill out the survey and pass it on to any other product managers who are not on this list. We’ll announce some of the key findings at Mind the Product 2012!

The post Product Manager Survey 2012 appeared first on MindTheProduct.

Many people know they should be doing experiments and testing their product but when starting out it can be daunting working out where to begin. So, below is my handy guide to experimentation built from scars received on the coal face of experimenting.

This post will take you through a birds-eye tour of the experimentation cycle with the aim of helping you get started and turning your experimentation into a process, something that becomes a normal and natural part of your product management.

The experimentation cycle consists of the following steps:

1. Plan
2. Implement
3. Monitor
4. Act

By closing the loop, the experiment results feed back into a) planning of experiments, b) the product backlog or c) development prioritisation. Similar in many ways to the OODA loop.

Figure 1: Experimentation Cycle

Experiments are done to make your product better. If the results of your experiments are not producing action of either new experiments to be run or changes to your product development then something is wrong in either your process or the experiments you are running. Remember, knowing what not to do is also making your product better.

In this article, I’ll begin with planning and designing experiments, move onto implementing experiments along with common tools and techniques and follow with by touching on running and monitoring experiments. To close out, we’ll look at actioning the results of experiments (re-starting the cycle).

Planning experiments

It is tempting to jump into running an experiment without doing any planning. This approach can work but is likely to make it more difficult for you to fully benefit from experimentation and implementing experimentation as a process.

Start with a question

A good starting point for the experiments is to ask a question and then come up with several hypothesis that answer the question. Once you have these hypotheses in place you can then design the experiments that either prove or disprove the hypothesis.

Let us consider an example. Conversion rate is very important for the company and driving that higher is a key objective. So the question becomes:

“Why isn’t the conversion rate on the landing page 30%?”

With the question in mind, let us now create several hypotheses as a starting point for testing:

1. The call-to-action should be a red button
2. The message is not clear about the value of registering
3. There are too many different call-to-actions on the page

Unfortunately, these aren’t very well written hypothesis. Lets bring some rigour to how we specify hypothesis so we fully understand what is going on. The traditional way to structure a hypothesis statement is to use an “if”,”then” approach, for example:

“if I water the plants then the plants will grow”

or structured slightly differently

“if I don’t water the plants then the plants will not grow”

So if we restate the above hypothesis in an if/then format they become:

1. if the call-to-action button is red then the number of people registering will go up
2. if we change the copy explaining the value of registering then the number of people registering will go up
3. if we remove all but one call-to-action on the page then the number of people registering will go up

Now the hypothesis states the independent variable (the bit after the if) and the dependent variable (the bit after the then). These hypotheses can be extended with a “because” clause which sets down why you think the causation exists. For example:

1. if the call-to-action button is red then the number of people registering will go up because the red button stands out on the page
2. if we change the copy explaining the value of registering then the number of people registering will go up because they will understand the value they get
3. if we remove all but one call-to-action on the page then the number of people registering will go up because they are not distracted by multiple call-to-actions

A good hypothesis is one that is testable with an independent variable that can be controlled and a dependent variable that can be measured. It clearly explains what is going to change and what the expected effect of the change is going to be.

A practical test of this is can someone else read and explain back to you what change is going to be made and what the expected effect of the change will be. If they can’t then you need to revisit the hypothesis. You want to be able to hand your hypothesis to someone who can then design the experiments necessary to test the hypothesis.

From hypothesis to experiment

Once you’ve got the hypothesis in place an experiment needs to be created that will test the hypothesis. An experiment will need to allow for the controlled changing of the independent variable (the bit after if) and measure the change (if any) of the dependent variable (the bit after the then).

If you have described your hypothesis well, experiment to test it will be obvious from the hypothesis.  For example let us design the experiment for the hypothesis:

if the call-to-action button is red then the number of registrations will go up

The experiment for this hypothesis is a template where the call-to-action button is red, but that is not the full experiment. You can’t be sure that any change in the dependent variable was truly down to changes to the independent variable. The dependent variable changes could have been caused by another independent variable. To ensure you produce a valid result you also need what is often called a control.

The experiment is therefore making controlled changes to the independent variable, measuring the dependent variable and then comparing the results against the control.

So for our example of the red button hypothesis, the experiment would consist of dividing website traffic between the already-existing page template (the control) and an identical page template with a red button (the variant), measuring the number of users who registered, and comparing the number of users who registered from the control and the variant. To account for differences in traffic to each template you should compare the conversion rate (number of registered users divided by the number of unique visitors) as opposed to the absolute registration count.

Figure 2: Going from question to hypotheses to experiments

You are unlikely to have unlimited resources and time to test every possible hypothesis. To help prioritise the hypotheses to test, focus on the hypotheses where the because clause is strongest based on your research and experience.

One test of the hypothesis is not going to answer the question alone. You’ll need to come up with multiple different hypothesis as the actual answer may not be obvious. Hence the need for a plan of what experiments you are going to run and what you will do with a positive or negative result. The more time you spend examining and defining the problem (the question and hypothesis) the better your experimentation process will be and the greater value to will achieve.

Final note on the question: focus on the questions that are tied directly to business value or KPIs. Some experiments can be attractive to run because they can be easy or fun to do but the more disciplined you on what questions you are experimenting on the more value you will gain from the experimentation cycle.

Build it into the company

Engage the rest of the company in the experimenting. This helps the rest of the company focus on what the end user is doing or valuing. By engaging the whole company into the process of experimenting it instills a data focused decision making across the board and helps with the HiPPO problem. Changing development priorities based on the results of experiments becomes accepted practice.

Another great benefit of involving the whole company in experimenting is it helps overcome the ego effects of having their work tested. Having your work challenged through testing is often confrontational for people and creates some resistance or disenchantment. However, by having the people create hypotheses and plan to do the experimenting from the beginning helps to change the perception of what is going on and the value behind it.

Implementing experiments

When looking at how the experiments are going to be implemented, consider that you don’t want to be tied into the engineering release cycle and resourcing. This provides the necessary flexibility to implement and monitor experiments on a schedule that produces the best outcomes. In effect you want to limit how coupled you are to engineering priorities and resourcing.

As you implement the experiments record the details of the experiment (name, where, what is it testing, variants), the start and end dates along with the eventual result in an experimental log. This serves several purposes:

• It helps you keep track of what is going,
• You have a historical record of tests run, the results and actions taken on the result
• It serves as a reporting tool for the rest of the company

When first starting out this recording may seem excessive but as experimentation becomes a routine process, the number of on-going and historical experiments will grow rapidly making it difficult to keep everything in order.

How to implement the experiment?

There are two basic types of testing A/B and Multivariate. A/B testing is comparison of 1 or more variants against a control (usually the current implementation) which proves or disproves the hypothesis. Multivariate is comparing what combination of changes prove or disprove the hypothesis.

An A/B test is one that would test the current call-to-action to the red button in hypothesis 1. A multivariate test is one that would test the what combination of red button and copy changes disproves or proves the hypothesis. Multivariate testing can be considered to be multiple A/B tests being all run on the same page at the same time.

Choosing between the two depends on:

• Your traffic
• Time available for testing
• Whether optimizing or looking for the big leap

Multivariate requires more time and traffic to produce a statistically valid result and is often best focused on optimising around a maxima.  The simpler A/B testing is better suited to finding better maxima and in situations where traffic and time is constrained. The A/B test will reach statistically valid result sooner than the multivariate testing.

Designing variants

Your variants will be driven by your hypotheses. The more narrow and specific your hypotheses are the greater likelihood that you are optimising around a local maxima.

The local maxima problem

Optimisation of the local maximum is a problem in that you never produce the big improvements. Instead you hover getting small improvements for a lot of effort. An analogy might help to explain better. Consider two hills a small one and a large one. You want to climb a hill to see the plain. If you keep your eyes on the ground and you are near the small hill, that is the one you climb and no matter how much you walk around you aren’t going to get higher. However, if you look up then you see the large hill and so can now get higher.

To avoid the local maximum issue, come up with variants that are widely different. This can extend to completely different layout, style and design of the variants. You are attempting to test different solutions that are as far apart in the problem space as possible in attempt to see the bigger hill.

It is very, very easy to experiment with small changes. It is safe and easier to convince HiPPOs. However, you run the very real risk of optimising over a local maximum. You can drive 1 or 2% improvements but nothing more. Take example homepages, instead of testing different copy test completely different layouts of buttons, copy and styles. These should be distinctly different layouts.

Real-life example

Figure 3: Control landing page

In a drive to increase the conversion rate at PeerIndex we did a series of experiments. The first set of experiments focused on moving buttons around on the page. This produce little improvement in the conversion rate.

Figure 4: This landing page had a 200% improvement in conversion

Next we did experiments on very different layouts which resulted in a 200% improvement in the conversion rate. The experiments showed the original assumption for the landing page, that we need to explain a lot about PeerIndex to get people to convert, was shown to be wrong.  By removing much of the information and keeping the pages simple we made the decision to sign up far easier. You can see the starting landing page in Figure 3 and the end result of the experiments in Figure 4.

Practicalities

Build vs buy

The perennial question: build or buy? You can of course have the engineering team create an A/B testing framework or you can use one of the SaaS tools available. As a product manager I lean towards the buy side as it reduces the impost on the engineering team both up-front and down the track as they don’t have to maintain the in-house system.  Additionally, I can run tests outside of the engineering release schedule.

Even with SaaS tool, you will need to get some engineering support to integrate the tool and also to setup your app to allow control by the tool. The extent of integration and engineering effort required depends on the service used but often involves including a JS file in the header of the site or app. Some tools (such as Google Website Optimizer – now part of GA) require you to tag the parts of the templates you are experimenting on while others let you use a WYSIWYG editor in the browser.

If you are testing quite different templates with potentially different dynamic data then you’ll need to create the templates and select the template when the page loads. With in-house you can have the template selection mechanism within the controller. Using SaaS tools, the most effective approach I’ve found is to use the split URL function and have the application select the appropriate template based on URL parameters. Split URL works by directing traffic to two or more different URLs. The difference could be a URL parameter (e.g. ?reg_flow=1) or could be completely different URL (e.g. http://www.example.com/page_1 versus http://www.example.com/page_2).

URLS

URL 1 = http://www.example.com/index?test=1

URL 2 = http://www.example.com/index?test=2

Controller

…..

IF URL_PARAMETER(‘index’) == 1 THEN

//do something

ELSE

//do something else

ENDIF

The same approach can be used to do experiments on different registration flows and the behaviour of different types of functionality. Implementing split URL tests do require engineering support so it is best to plan out the tests you are planning to run so the modifications can be scheduled for engineering delivery.

The challenge with using split URL tests is being able to fire the right goal. If the goal is pageview, it is straightforward. It gets trickier when the goal is an action e.g. successful completion of a tweet, sending an email or submitting a form. Some of the tools captures these actions out-of-the-box or provide a “custom” goal method that you can setup to fire on successful goal completion.

Choosing a SaaS tool

There are a variety of SaaS tools available with 3 notable ones being:

• Google Website Optimizer (now integrated into Google Analytics)
• VisualWebsiteOptimizer from Wingify
• Optimizely.

I’ve used all three and all 3 get the job done. Here are some quick notes on each.

Google Website Optimizer

I found Google Website Optimizer underpowered for the type of experimentation I was doing and it required a lot of manually tagging of the templates in order to run each separate test and was impossible to use to test functionality.

Optimizely

Optimizely includes a WYSIWYG editor (which got indigestion with large web pages). Unfortunately, I found the navigation around the experimental results, editor and dashboard to be confusing resulting in a lot of experiment re-dos and a lot of thinking trying to work out what particular aspect of the service I was looking at.

Visual Website Optimizer

I ended up using Visual Website Optimizer as my primary tool for experimenting as it provided me with the tools to support the experiments I was doing had a straightforward experiment creation process and the UI presented the results in manner that I found clear and easy to navigate around.

Test well

It is easy to try short cuts when experimenting. Unfortunately, shortcuts can easily invalidate the results if you’re careless, making it problematic to draw conclusions from any results you get. Make sure you follow the scientific method.

One common shortcut is to continually change the control. For experiments to avoid observational error the control needs to stay the same through the experiment.

The other major issue is transient traffic, for example from PR. PR (say being on featured on Slashdot) drives a significant amount of transient traffic that may or may not be your target traffic. So your experiments will become overwhelmed by the behaviour of the transient traffic instead of your target traffic leaving you to optimise for the transient traffic that quickly disappears as soon as it came. Dealing with transient traffic it is best to ignore the period during that it occurred and only use the results from either side of it.

Segmentation is very important

Learn to love segmentation because segmentation allows you to understand and optimise for different users.  There is no point in getting a 30% conversion rate in the wrong market which masks the fact you’ve only got a 5% conversion rate in your target market.

For example of what segmentation can provide, I’ve run tests on segmenting conversion based on country of origin. What this showed was that the conversion rate in our target markets was lower than the overall conversion rate because the conversion rate in other markets was considerably higher masking the lower conversion rate. We are now planning tests aimed specifically at getting the target market conversion rate much higher. If the segmentation hadn’t been done, we’d never have known this.

Segmentation can de done a variety of features such as:

• Browser
• Country
• URL parameters (utm codes)
• Time of day
• Day of week
• Visitor type (new versus returning)
• Search keywords
• Mobile device
• OS

Running and monitoring experiments

You’ve got your test plan in place, you’ve implemented the tests now it is on to running the experiments.

Experiments take time

Running the tests will take time even if you’ve got good levels of traffic. The primary reason is to achieve statistical validity. For a test to be statistically valid you need to run it long enough to have enough people to participate in the experiment. How much is enough? Without going into the math involved you can get an idea of how long you’ll need to run an experiment based on traffic levels and complexity of the test using this calculator provided by VisualWebsiteOptimizer.

Also effecting statistical validity of the results is the traffic behaviour. Even if you have enough traffic to get valid results in a single day, is your traffic on that day the same as other days? Was it affected by a marketing push or PR event? You have to take these into consideration when selecting the time the test for run. I prefer to run a test for a minimum of a week so that the experiment is run across the different types of traffic that come by a site on different days of the week and times of day. PR or marketing pushes may require the test to run longer to allow time for the traffic to return to normal.

When you have low traffic you’ll have to run the experiment longer to ensure you have valid results. Here are some good tips on running experiments with low traffic.

Reporting

Reporting serves one and only one purpose; help you determine the next course of action where that is more experiments or changes in product/development prioritisation. If no action is achieved then the report and experiment has been wasted. The reports only need to be as good as needed to draw a conclusion and take action.

The reporting stage is where you get to ask, “why”? Why did I get x instead of y? These questions will lead to new experiments (they are a question remember) that serve to continue the cycle, the process of experimentation. It shouldn’t stop with one experiment or set of experiments. This is also the point at which to examine anomalous results. By anomalous result is one which neither proves nor disproves the hypothesis but one that is perpendicular to what was being tested, one that is so out of expectations should focused on to answer why.

An example of this is a test we did at PeerIndex segmenting the landing page by country. The hypothesis was there would be a difference between the different locations and there was. The anomalous result was one country had a result that was 50% greater the rest. There is no obvious reason for such as difference between that country and the others. In fact it even isn’t a target market.

The importance of negative result

The key outcome of testing is to learn. The result whether positive or negative is immaterial, what is material is that you learnt something from the test. A negative result can and often is more important than a positive result. The negative result is telling you that your fundamental understanding of the user is wrong. The result is you can then go back to the drawing board and use testing to discover what the user wants.

Closing the loop

You’ve designed the experiment, implemented it, ran it and now have the results in a report. The next step is to ask yourself two questions:

• What do these results mean for development prioritisation? and
• Why did I get these results?

The first question allows you to review the development backlog and adjust the prioritisation based on the validate results you got from the experiment. This way improvements in key metrics found in the experiments can be made permanent and are deployed as quickly as possible. For example, if your experiment produces a 100% improvement in conversion rate then you want to get that out as fast as possible.

By asking the question “Why did I get these results?” (or conversely “Why didn’t I get the results I expected?”) you come up with hypotheses that could answer it which you then design experiments to test. For example, say you had done a experiment that showed that visitors from different countries converted at different rates with your target market countries converting lower. The question is then “Why did my target market convert lower?” to which you come up with hypotheses to test.

The actions that are taken based on the results (product prioritisation changes, new experiments) should be recorded in your experimental log. This provides a way of keeping track of the experiments and the eventual outcome. It also provides a handy trail to keep track of how you arrived at any particular experiment.

It is unlikely you’ll answer any question with one experiment. Instead you are more likely to iterate towards the answer by doing repeated experiments. This ongoing experimentation cycle is how you can more rapidly evolve the product to meet KPIs and objectives.

Summary

Ultimately, the goal of experimentation is to achieve a business or product objective. Keep that in mind and you’ll do well with experimentation. However, lose sight of that you run the very real risk of short term optimisation that fails to build a strong product or business. It is not about running tests for tests sake or to tick a box in a framework checklist. All the experimentation has to be grounded in achieving a stated objective.

You need to be able to ask yourself “How is this experiment aligned with this objective we are trying to achieve?” and there should be a clear answer e.g “Our objective was to increase revenue. This requires more users paying for the product. We wondered whether the CTA on the home page could be more effective to get user to sign up. One of the tests is the emphasis on the CTA button. This test is one of these – where we evaluated different colours of button.”

Experimentation brings the scientific process to product evolution with the goal of achieving an objective faster. Even if you start out only on experimenting on one area (say landing page conversion) over time you will be running experiments on many different parts of your product at once. Remember the process and tie each experiment into an objective and it will be much easier to keep track of what is going on and ensuring your experiments are evolving your product towards the objectives.

You can find other interesting details and tips on experimentation in this Smashing Magazine article.

The post Everything a product manager needs to know about experiments appeared first on MindTheProduct.

Many people think of user research as either something you do towards the end of the project as a check and balance before going live, or once the project has already gone live to make sure it’s working as it should. However, research doesn’t always have to focus on what you have created. It can be done much earlier in the project to help prioritise product requirements by looking at solutions that already exist in the market.

Overwhelmed with ‘cool’ ideas

Let me demonstrate the value of this exercise from a project I was involved with. We were called into a situation where a product team was overwhelmed with requirements and ‘cool’ ideas for a new high profile community website which would accompany a TV show.  The product manager was struggling to stem the flow of ideas and get everyone to focus on an agreed scope. It didn’t help that the very excitable client kept adding more and more requirements to the list.

A feeling some of you might empathise with: they felt they didn’t have the time for research, they just needed to get started. After some discussion they conceded that they couldn’t afford to accommodate all the requirements and needed an independent perspective on what they should focus on. So we kicked off a piece of user research to validate their list of requirements.

More focused list of validated requirements

A week and a half later, we had conducted several research sessions with target users and listed all of the core requirements users had for the new product. The research was focused on understanding what users needed, what they currently used, and what they would need the product to do in order for them to switch to it. Essentially we sat next to target users in a one-to-one session and they showed us which websites they used.

We observed how users interacted with competitor’s offerings while they explained what they found useful, what was frustrating and what they felt was missing. Then we asked them to complete tasks on  a variety of other websites which contained the features and functionality being considered as potential product requirements. This gave us insight into which content, features and functionality worked for users and which did not. We were able to establish which of the product requirements were valid and which would be unlikely to offer users anything more useful or different than existing offerings.

Comparing user requirements with the previously generated list of requirements quickly allowed the product team to isolate new core requirements which would meet the needs of the business.  A list of 63 requirements was whittled down to 17 which were focused, manageable and more importantly everyone on the project agreed with.

Months later when the site went live, users loved it and the client used it to showcase the site internally as a great success. The product team were delighted they hadn’t spent valuable time and resources developing for requirements that users simply didn’t need.

Steps involved in user requirements research

A research project doesn’t have to take weeks, a good UX researcher should be able to develop a focused research plan to tackle you’re list of requirements. Here’s a simple breakdown of the core steps to consider:

• Pick some websites that offer similar functionality and include these in the test
• List the questions you need answering in the research. Make these as detailed as possible i.e. Do users experience any confusion when interacting with the search filters on ASOS.com?
• Investigate what users need from this functionality: what helps and what hinders?
• Establish what they currently use and identify what’s missing from their experience
• Explore what would make them switch from what they currently use to a new service
• Draw up a list of user requirements and compare against your other requirements

At the start of a project, testing products that already exist on the market can put you in a great position. Before any scope document is agreed or any code is written, you can establish which requirements will really help users and which probably won’t be worth the effort.  Having an in-depth understanding of what users need from your product so early can help you focus the entire product team on those features which will really offer a great user experience to your target audience.

The post How user research can help prioritise product requirements appeared first on MindTheProduct.

He warns that one size does not fit all, and that the approach they took was very much aligned with their overall strategy, with a commercial imperative and a direct relationship with customers through their subscription model.

The goal – The pleasure of leisurely newspaper browsing with the immediacy and interactivity of a website

Their first iPad app was a native iOS app, and was very successful – with over 1m downloads, incremental subscriptions, and winning Apple’s Design Award.

But then Apple’s rules changed and took the FT by surprise. The main change was that the subscription billing had to go through Apple, severing the direct customer relationship. This also meant the FT couldn’t fulfil it’s promise to their users of having one subscription, one login.

Ultimately, this drove the FT to develop a new version of the app in HTML5. This actually increased their audience, even without any marketing and allowed them to quickly and easily roll out Android, Windows 8 and even Xbox Kinect versions.

The post Video: The Financial Times mobile strategy appeared first on MindTheProduct.

Back in the 80s and 90s people often likened design to art, that the creatives vanished behind a curtain, did something magical and produced it with a flourish. While that metaphor is dead, we need a new metaphor to describe the design process.

Harry proposes that design is like detective work, which involves ascertaining what actions certain people carried out within a given context using certain tools. Digital product design is very similar, except it tries to predict what people will do in the future – and puts the tools centre stage. What’s important is that detective work rarely leads you directly to the solution, you have to chase down many leads and test many hunches first.

Watch the video to see how Harry and Clearleft applied this metaphor to The Week, and how their “failures” ultimately led them to the solution, and an award winning iPad app.

Other perspectives on The Week’s iPad app
“The Week” iPad App – Lessons Learned From A Product Manager
Video: The Week iPad App’s Business Case

The post Video: The Week iPad App’s UX Approach appeared first on MindTheProduct.

The Week is a weekly news magazine, published since 1995. It is one of the UK’s most successful magazines with around 170,000 subscribers which makes this a classic challenge of taking an existing product and having to work out how to transfer it to a new platform.

Watch the video to see how Dennis turned The Week into a successful iPad app with over 250,000 downloads globally, 65% 5-star reviews and placing in the Top 5 iTunes News app in 38 countries. You can also read more in “The Week” iPad App – Lessons Learned From A Product Manager.

Other perspectivess on The Week’s iPad app
“The Week” iPad App – Lessons Learned From A Product Manager
Video: The Week iPad App’s UX Approach

The post Video: The Week iPad App’s Business Case appeared first on MindTheProduct.