Why We Still Need Research

Whether you’re apart of a start-up looking to change the world, or like me,  apart of a firm riding the waves of introducing and intreating products to an established audience – being able to efficiently deliver, measure and validate product and design decisions is something we all aspire to. This is pretty much basis of lean and agile thinking.

The concept of continuous improvement in efficiency and product value appeals to be me greatly, and this can potentially place less emphasis on the need to get things right up front, thus decreasing the need for up front market research and testing efforts.  This way of thinking aligns more to the startup that aims for disruptive innovation then anything else, where products are are for an audience no-one really knows about yet. How can you research the needs of people you don’t know about anyway?

I want to agree with this way of thinking but not without overlaying the reality of what it really takes to develop products, particularly in the established firm space, where you’re iterating sustained innovation for existing customers with researchable needs. Think about these few things for example…research

1. Building software is f@uckin expensive and takes a long time!
These days we can just about build whatever we want, the challenge is building the right thing. You have to make every effort you can to reduce the risk of spending a LOT of money and time on something irrelevant to your existing customers.

I’m yet to be apart of a team that can get something out that validates assumptions of value in a matter of weeks. It takes months. Even if it appears that your initial product is light on features – you’ve probably been working  on  an “ice burg” project where the majority of effort thus far isn’t visible to the users eye  - like spinning up environments and services, data sourcing and data security. Having said all this though, I do love Eric Ries’s story about how he could have saved a year’s work (on a product hardly anyone wanted) by testing the interaction of a “coming soon” landing page. This is a fantastic example cheap and effective research, but potentially harder to get away with when you already have a large brand and user-base. I tend to think that the more established you are, the more impetus research needs.

2. You’re too close to notice the obvious
Have you ever been working like crazy on a new app or site and proudly shown the folks at home what you’ve been up-to at work? There’s usually that comment where you think – that’s a fantastic way to solve problem [x] and we couldn’t for the life of us come up with that at the office. Why does this happen all the time? It’s because you’ve received feedback from someone with distance from the project with a fresh and unconstrained view point. This is research. Dan Pink agrees.

3. Direction and decision justification
When working on products you’ve probably found that many decisions need to be made – ranging from the fundamentals – who’s it for? what’s the value? what scope is going to facilitate this value? – to the visual, what’s the main colour? what are you naming this thing? are you sure those images are the right size? You’ve also probably found that when making these decisions,  everyone concerned about what you’re doing will have an opinion that may or may not be in-line with yours.

Research can be used to justify these decisions – it can provide insight into any of these areas, insights  you can rely on when the (internal subjective opinions) jury is still out. It can affirm what you think is the right thing to do, and  more importantly it can prove you wrong, when you are and allow you to realign before mistakes become costly.

4 Ideas On Allowing Innovation To Work In Established Firms

Investing in innovation inherits risk, because the chance of success or what new market (and it’s size) might arise from the innovation is largely unknown. The problem with asking a mainstream business to be more tolerant to this risk-taking with inherently higher probability of failure, is that they simply can’t tolerate any marketing or product flops.

The main business should only invest in sustaining technology, into existing markets made up of well-known customers with researchable needs. Getting it wrong the first time does not bode well with this well-known processes of careful planning and co-ordination.

Markets come and go – and companies need to transcend from one to another for a real shot at continued growth and longevity. But this needs to be supported by markets and customers that the core business can’t even afford to understand little own make money out of. So how can a company make inroads here?

1.  Put a tiger team in a bubble
For established firms, spinning up an independent team to establish a strong market position in emerging technology is easier said then done. It proves difficult to do, you’re essentially re-allocating people and efforts away from the needs of the core customer base, who currently pay the bills. It’s been proven successful though – IBM’s PC Division, Hewlett Packard’s desk-jet initiative, Control Data’s 3.5 inch disk drive efforts are all examples of companies allowing independent teams, shielded from the overall organisational structure to go off and successfully build out new value for emerging markets.

In these examples independence and autonomy were created, talented staff were assigned to the initiatives and were completely protected from the constant business as usual distractions they would have encountered otherwise.

2.  Make learning their objective
First up acknowledgements must be made – a realisation that small, largely undefined markets cannot solve the growth and profit problems of large corporations. Learning about what the market actually is must happen first. It may take multiple pivots in a teams direction before they strike gold. Listen to what the market is saying through metrics and feedback. If you see en-expected  spikes in unassuming areas of a product – this could be a subtle clue to where you should focus next. Maybe you can forgo scope for a new type of application. The important thing is to observe and validate (or dis-prove) assumptions fast and pivot in the direction the market leads you – even if at first the indicators are small.

Take the story about Honda’s invasion on the US motorcycle industry for example. They researched the market and found that US riders loved riding long distance on the powerful machines. They attempted to build motorcycles to meet these needs and competed against the likes of Harley Davidson in this well established market. They failed dismally.

The interesting part of the story is that Honda’s Japanese executives working in the US were given Honda Super Cub bikes for commuting around LA, where they were based. One exec began to vent is frustrations on the dirt roads of LA’s surrounding hills. Over time he invited friends, who loved the experience. He had discovered a new application for the Super Cub. This was essentially the beginning of dirt bike riding in the US – a new market that Honda established (by accident) and then owned for decades to come.

dream-super-cub
Honda’s Super Cub Motorcycle

3. Get pumped about the small wins
In the early years of a new business, income is likely to be denominated in the hundreds, not tens of thousands. If a start up is able to get a few early wins, they will be relatively small ones. Ina small independent organisation these small wins will energise a team with enthusiasm. However, in the mainstream business a small win will be met with scepticism. People will question whether there’s enough value generated for ongoing investment. As a manger the last thing you need to be doing is waisting time and energy defending the teams existence to the overarching efficiency analysts.

4. Be proactive in understanding potential new applications
As a company you need to be acutely aware of emerging new applications that can leverage the value of what you have to offer, the timing here is critical. Hewlett-Packard’s Kittyhawk Drive is a great example in this space. HP worked tirelessly on Kittyhawk, it’s emphasis was on a size, weight, power consumption, durability and ruggedness. It was intended to sustain the portable computer and PDA market. It’s development went to plan and it had the hefty price point that manufacturers like Apple could afford.

The PDA market never took off back then (Apple’s Newton flopped). And HP was left with a product that was over designed and over priced for the likes of other disruptive applications that really took off – think digital cameras, scanners and portable word processors. In this instance HP weren’t privy to these emerging applications and the huge new markets they would create. Even if HP could have afforded to re-design and re-position Kittyhawk for these needs, the window to enter the markets would have by then been shut.

References
Kittyhawk Wiki Page
Honda Super Cub Wiki Page
Innovators Dilemma – Clyton Chrstensen

Disruptive Sony circa 1950

akio.morita

In early 1952 Akio Morita took residence in a run-down New York City hotel. Morita was a co-founder of a small Japanese company by the name of Sony. His goal in NYC was to negotiate a license to AT&T patented transistor technology. Morita found AT&T to be uninspired with what he had to offer and a less-then-willing negotiator. He had to visit the company repeatedly badgering AT&T to grant him a license.

Finally AT&T relented and after the meeting where the licensing documents were signed they asked Morita what Sony had planned to do with the technology. “We build small radios” Morita replied “Why would anyone care about smaller radios?” they queried “We’ll see” Mortia answered.

Sony soon after introduced to the U.S. market the first portable transistor radio. With far lower fidelity and a lot more static then the table-top designed radios that were dominant at the time, it was fair to say they sucked.

The important part of this story  is that rather then working in his lab to try and be performance competitive with the table top offerings, Morita instead gambled on a new market that valued different attributes in a radio – being portable and personal.

After Sony’s disruptive innovation none of the leading producers of table top radios were able to succeed  in the portable radio market. The horse had already bolted and Sony was riding it first across the finish line.

Sources
Akio Morita Wiki Page
AT&T Wiki Page
The Innovator’s Dilemma – Clayton Christensen

The Innovation Challenge

The reason why innovation often seems to be so difficult for established firms is that they employ highly capable people and then set them to work within processes and values that aren’t designed to facilitate success of the task at hand which is often outside the mainstream business model.

Ensuring that capable people are ensconced in a cable organisation is a major management responsibility in an age such is ours, where the ability to cope with ever accelerating change has become so critical.

Clayton Christensen.

Kanban For Product Managers

Lean and Kanban adhere to certain rules. Some of these rules can, and should be applied to the  development of software.  These include the concepts of eliminating waste, maximising production flow, empowering workers, continuous improvement and forming partnerships with suppliers.

The above concepts are what any good team will strive to achieve by using Kanban signaling on  walls to help visualise and stem workflow through analysis, development, testing, etc – to achieve optimal workflow through the whole team. Some times though blockages and bottle necks to flow can occur well before work hits analysis and development within the delivery team. So maybe us Product Managers can apply Kanban techniques further up the flow of work where requirement definition resides?

trello kanban
Trello is great tool to manage your own personal Kanban system.

Try viewing your project stakeholders as suppliers and their requirements and scope as the parts that we need to complete our product.  As a product manager you can use elements of Kanban to schedule the supply of these parts just in time for development thus avoiding blockages within your area of responsibility, that can impact the flow of dependent delivery teams.  Below are some pointers for implementing a Kanban system to improve the flow of your own work.

  • Visualisation and transparency of this work is key
  • Split out tasks into discrete pieces of work that you can card up
  • Limit yourself to only be working on 1 – 3 cards at any given time
  • Specify the date you kicked off the activity and write this on the card
  • Specify when you’d like the card completed, thinking about when the requirements will be needed in development – write this date on the card
  • Measure how long it takes to complete each card by placing a red dot on the card for each day its in play
  • Experiment to see if more red dots occur on each card when more are in play at the same time
  • Report on the % of cards that you completed on time. On review of this data you can tweak concurrent work, distractions, etc if not meeting timings
  • Have a prioritised backlog of cards, and review regularly
  • You could find a space to start your own Kanban wall of activity
  • If you can’t find your own wall physical space, there’s some great virtual wall tools (that you can take with you anywhere), like Trello and LeanKit
  • Its important though to keep stakeholders and your delivery team across the activity of your wall – be it virtual or physical

Who Are Your Users?

Any feature or initiative we deliver should enable us to learn more about our users. It could be something where we extract explicit pieces of data like form that asks for peoples details, or it could be something where we imply peoples needs, based on the behavior they exhibit on your site.

This is all well and good, we need to be doing these things – but what comes next? How do we do something meaningful and valuable (like personalising our services) with all this intel that we’ve attached your users? This explains a way this could be done from a 30,000 feet view.

Buckets of personas
Developing a personas can be really valuable. Personas can be what ever we like, they could be buckets aligned with user outcomes. Personas can also be aligned to peoples underlying motivations, attitudes, income levels, family situations and locations (amongst other things). This type of classification is the bread and butter of Roy Morgan Research and their Helix Personas. Here you can find 7 different communities, including ‘Metrotechs’, ‘Todays Families’, ‘Getting By’ and Golden Years’. These communities consist of 56 different personas for example within ‘Metrotechs’ you can find personas like ‘Social Flyers’, ‘Fit and Fab’ and ‘Big Future‘. When you dive into these personas you find rich and detailed information about who these people are. For example ‘Big Future’ people span across genneration X and Y, they’re often married with kids, they live in houses rather then apartments, they’re employed,  they work too much but at least they earn enough to enjoy life (if they have time). Just for arguments sake, say we employed these Helix Personas – this would mean that everyone who visits your site would fall into one of these 56 persona buckets.
consumer_data_model (3).png
The foot in the door to linking a consumer to a persona
The cool thing about these personas is that they are linked to residential addresses. Once you extract an address from a consumer the list of personas that the person could belong to begins to reduce, sometimes  drastically. You might find that there are only 4 out 56 buckets that a person could fall into simply by knowing their address. You might also be able to determine a % likelihood of which persona they are, based on persona coverage within the suburb e.g. Bucket C covers 60% of the Springfield suburb.
consumer_data_model (2).png
It might not be that hard to be super accurate
So say you’ve whittled down to only 4 personas for a particular person. Maybe there’s only couple of extra data points needed to determine exactly which persona they are. This could be something like date of birth and household income. We could also imply this type of profiling by assessing the types of products they interact with and purchase on your site. This might be all it takes to have a 1 to 1 relationship between a person and their persona.
consumer_data_model (1).png
Predicting what happens next
If we understand what a persons existing persona is, we can also predict what persona they’ll be heading too next and when. For example their might be a strong pattern of ‘Coupon Clippers‘ migrating to ‘Frugle Living‘ over certain amounts of time, thus allowing for automatic updating of personas inline with changing lifestyles.
consumer_data_model (4).png
In summary
Whether you establish your own user buckets or use a 3rd party set like Helix Personas – being able to classify your consumers is core to really understanding who they are. Helix Personas are appealing to me because they make inroads around what people are actually thinking at a deeper level, tapping into the needs and wants that determine their behavior. Imagine if you knew with a high degree of certainty that consumer x is trying to get one of the kids into the local school for a good education, is looking to buy a car big enough for the growing family, is probably a liberal voter, is ambitious and well paid, looking to move in 6 house in 6 months to upsize, will retire in about 25 years, etc, etc. This would allow for powerful targeting and personalisation of the services you offer, be it media placement, promotional offers, site and app experiences and push notifications.

Really understanding peoples needs and moulding experiences to suit them so that you can assist them with their real world challenges should be the ultimate personlisation goal. Perhaps a good starting point would be to come up with a categorisation model and a way to funnel consumers into these buckets based on the data they generate on your site or app.

10 Things To Remember When Delivering Lean

Every digital company should have at least heard of being agile and delivering lean. These are wonderful things that can enable teams to deliver the right change at the right pace. But how do you make sure that the change is right for your customers and colleagues? Hopefully the below points can help you out here.

Build Measure Learn Loop

1. Make calls based on raw numbers over percentages.
Always know the popular features are and the features people won’t miss. Assessing usage stats in what ever reporting platform you use should take place before any scope decisions are made. Avoid making calls by percentage of use, look at the raw numbers. 1% might still equal thousands of visits or views each week.

2. Are you replacing something or building a shiny new thing?
If you’re rebuilding an existing feature aim to achieve feature parity with the experience you’re replacing. At the very least understand which features must not drop off by assessing your metrics. When introducing a brand new feature, there’s a lot more tolerance about going out light-on and iterating functionality over time.

3. Do you need to refer back to the old experience?
When updating existing features, provide an obvious link back the old experience. Give people time to absorb the new experience and create new mental modals around how it works before taking away access to the experience they got were to.

4. Arm your customer support and social teams with the answers they’ll need.
Think about what’s changing? What’s missing? What’s new? Do you have plans to introduce more scope over time? How will all this impact your users? And most importantly why have you made these calls? The answers to these questions should be conveyed to those who talk directly to customers via support and social channels.

5. Be across the feedback.
Understanding customer feedback is paramount. Feedback will always spike when change is introduced. It’ll mostly be negative, sometimes constructive and on the odd occasion you might even get a compliment. Don’t be disheartened by this, people aren’t inclined to pipe up just to say well done. If they’re happy, you won’t usually hear from them.

Each customer has their own story about how they use your product to solve their real world problems. Know the edge cases and look for patterns, does what you’ve delivered provide a solution for these?

6. Have your iteration plan ready.
We tend to move on (after a brief celebration) to the next epic on a road map as soon as we deploy a feature. This can be a mistake, especially if you’re replacing a feature without all the bells and whistles that a previous version had. You need to build into your road map subsequent releases of a feature that take into consideration market feedback. Always remember that the first deployment of a product is only the beginning of it’s life.

If and when people complain about something you’ve changed, ensure that you’re across it and that you have the ability to reply these people once a subsequent update to the feature addresses their concern. You can convert them into passionate followers with this kind of attention. You’re showing them that you really care about their needs by address their issue and getting back to the them about it. Even if you don’t plan to address a customers concern, letting them know this is far better then ignoring them.

7. Split test if you can.
A/B testing should be best practice is this day and age, thats not to say it’s easy though, especially when working with an older site that’s already on its knees performance wise. Essentially we are always striving for some sort of conversion, be it a purchase, upgrade, reveal, save, submit, view, call, create. The elements we use to entice people to partake in these actions can all be candidates for split testing. If we aren’t adding a little science around understanding which variation of an experience ensures the best conversion of these actions, then we are merely assuming that the single experience delivered will provide the best outcomes.

8. Strive for feature parity.
People now expect feature parity well beyond the desktop. Mobile devices and data networks are now capable of facilitating this expectation. From a delivery point of view you want to be making the right fundamental decisions up front, before anything is built. Ask yourself – what will give you and your team the best chance of providing a consistent multi-device experience? It might be worth wearing more initial overhead to build out a responsive web app. It could take you longer to get an MVP to market, but this is an expectation you can manage. Once deployed the advantage kicks in with efficiencies in effort when iterating for different device dimensions and resolutions from a single app.

9. Don’t get carried away with internal objectives.
Day in, day out you will be inundated and influenced by the language and behaviour that occurs with in the walls of your company building. This is all good, but don’t let this get you too focussed on internal definitions of success. Targets in visits, time on site, engagement, sign-ins, whatever it is – these are all means-to-an-end and can be subjective. The true definition of success is harder to measure or even define, but it lies within really understanding true real world problems that people encounter (and they may not even realise they encounter them) and providing genuine solutions to these problems. I find that satisfaction survey results and verbatim user feedback are the best barometers as to whether you’re nailing it or not. If you are nailing it here, then the internal objectives that define success should be a by-product.

10. Find the right engagement model.
For me this ones the most important. How do you ensure that you take your colleagues (who aren’t directly apart of your delivery team) along for the ride? Think legal, sales, social, finance, media, security, marketing – they will have opinions and requirements that they’d like you to at least consider.

Do you engage them all at once, in small groups, individually or is it a combination of all of the above? If everyones clear on what’s happening and their individual expectations are being met – good for you! If there’s uncertainty, confusion, people feeling like they’re being left our and worst of all ‘dreaded surprises’ – then you need to change, and fast. The only thing I know for certain is that the model you used for your last project, probably won’t be as applicable to the one you’re doing now. You have to be astute and gauge how much you and your stakeholders are getting out of the current model, then act appropriately.

Lets use marketing as an example. They are working with a third party agency to communicate the value and particulars of your product. However when delivering lean in an agile environment, things can change fast, sometimes daily. This said it’s easy to fall out of sync between the marketing campaign and what’s actually being built. The ideal way to prevent waste and delay here is to convince your marketers to co-locate with your team, so that they are actually apart of the delivery team. But they have their own agendas so this approach might be asking too much.

My fall-back advice is to invite them to stand ups, have a weekly time-slot booked in with them, be on the front foot about keeping them up-to speed on an ad-hoc basis. It also helps if you can give them degrees of certainty regarding certain scope items and go-live dates, so that they can confidently build this information into their campaigns. Even asking your designers to use marketing approved images and copy in concepts and Photoshop files will prevent unnecessary double-handling when the marketing and/or agency designer eventually inherits the files.