Why I practice Code Therapy

code
For me programming has always been a very creative activity, like drawing, playing an instrument or gardening. There is something about sitting in front of a computer and realising that there are endless possibilities to create something almost magical, if I just put my mind to it and figure out how it works.

I started at a relatively young age of 14 to explore the different possibilities with Amiga and PCs. By then it was all about games and making pretty graphics float around on the screen. The big revolution came of course with the Internet and web browser. Thanks to HTML it became even easier to create something colourful and best of all; I could show it to anyone by sending a link in an email. Few things have blown my mind more than that.

These days I don’t work as a programmer any longer. I realised I would not be the best of what I did and I found it more compelling to focus on the business side of what the products could do, rather than the actual code writing.

So I practice what I’d like to call Code Therapy instead. I sit for hours on my spare time and build small products and services with the few programming skills I have. Sometimes I explore a new framework for responsive design or implement a small user login against a new database or test integration possibilities against different social media services.

I have probably about 50 or 60 unfinished projects on my computers. For some of them I of course initially thought they would make pretty decent products one day, but I did not have the time or motivation to finish them. About ten years ago this was rather depressing. Why could I not get my products out there? But I later realised that the products that I didn’t finish wasn’t really that awesome to begin with. And it wasn’t a waste of time. It was practice, it was exercising my brain, it was creative. Most of the code was also later used in other products, that did go live.

The most exciting thing about this is that when I talk to other developers, almost all of them are doing the same thing! They build stuff and leave it to grow old on their computers. It’s just early sketches. A part of their legacy as code artists.

For me the Code Therapy helps me understand what new technologies can offer and what business opportunities we can develop from it. Also it’s a way for me to escape reality and put my mind to work, solving a puzzle I created myself with pieces I find on the Internet.

I hope more developers will stop feeling bad about their unfinished projects and realise it’s not a waste of your time. It helps you grow. Personally I would never hire a programmer who was not coding on his/her free time. Please send me your thought via twitter or the comments below.

Photo by: Riebart

3 contradicting definitions of mobile strategy

“We need to go mobile”. Well, what does is mean? Here are 3 definitions of “mobile” that totally contradict each other, and you need to consider them all!

In a world where “mobile first” is a mantra for new startups and expressions like “adopt to mobile or die” scares and confuses the established market leaders I think it’s time to punch a hole in the bubble and define what we really mean.

1) The mobile technology

When is a device mobile? When you can carry it around? in that case, everything from laptops to mobile phones are mobile. But that’s rarely what we mean. We usually mean “mobile phones”, but the concept recently became more complex with tablets entering the arena.

What this really boils down to is that mobile phones and tablets are built on a different platform than old fashion computers with different user behaviour. We use touch and gestures rather than keyboard and mouse. We use apps over surfing the web. Your strategy for mobile technology need to include how your user will use your product. Are you building an app or a website. If you are using video or audio, is it in a format that is supported by mobile devices? Can you (and should you) use the same third party services like before, like ad server or analytics tracker?

2) The mobile screens

Screens in different sizes have been around since the dawn of Internet, and in the beginning it was a relatively small variety. With phones and tablets getting access to the internet, the previously rather small issue became larger and poured gasoline on the fire for trends like responsive web design.

Adapting to the different screens is not a mobile strategy, but we like to call it that because it’s phones and tablets that look bad. Today, there are hundreds of screen sizes – from smart TVs to mobile phones, so you need to have a scalable screen strategy for different ways of viewing your data in your app or website.

3) The mobile customer

Your customer can user your product anywhere. If they can’t you are doing it wrong. But with mobility comes lots of opportunities and considerations. Your users’ connection to the internet can vary a lot. They can use your product in the comfort of their home, abroad or for just five minutes on the bus.

For an e-commerce company this is particularly important. In what location and when are customers likely to develop purchasing behaviour. Are there some products that are more interesting when they are at work or at home? When are they likely to show something they found online to a friend? Are they more likely to discover a product on Facebook than on Google when they are on the bus? When will the customer complete a purchase transaction? Your strategy for the mobile customer has very little to do with technology and very much to do with marketing. Be sure to get the strategy right and know your customer.

These three perspectives are scratching the surface of ”mobile” and are closely tied to how we as consumers (and producers) are developing new user behaviours. I would love to hear your thoughts on this.

Picture by: Garry Knight (CC)

Product managers that create that special magic

product-stakeholders
Are you a product manager? Then this has definitely happened to you (and here’s what you can do about it).

Your product team starts developing a new user profile page. Mid development your system architect lets you know that this will impact the data caching and will add more development time. How much? It’s hard to say. The problem is really complex…

Next, your designer has finished the UI design. You both think it looks really good, but the designer added a few more data boxes to the design and you originally talked about. Alright, we’ll have to try and squeeze that in there.

Development continues, but is roughly aborted by the head of PR saying that we just signed a deal with a really important partner. It’s imperative that we rebrand our startpage asap to reflect this. Ok, some people are put aside to work on this.

Then everything breaks. Customer service get bug reports on that the payment process is broken. The CEO does not like the new user profile design. All development gets delayed. Team morale is at the bottom.

Who’s fault is it? Yours.

Being a product manager is about making hard choices, setting a strategy that benefits the entire company and making sure that all stakeholders are happy with this. In the case above (which we all experienced) the product manager failed to analyze and explain the implications of the different changes that came in from the side to the people suggesting them.

As a product manager you need to know the product by heart and still not be the domain expert in all the details. You must not be afraid to ask the question “Or what will happen?”. It’s really easy for a developers to say “We need to fix this or the site will break” or a PR manager to say “this partner is what will allow our business to take off”. As much as you need to trust their judgement, they need to motivate why, and how it will break or at what level it will benefit the company. The same goes with marketing, sales, pr, customer service and design. You need to get the processes in place to get the right information in the right time to make the right decisions.

To get past it’s a lot of work. You need to manage changed customers demands, internal politics, loud and passionate co-workers with huge pride in their individual work and the constant risk of making a bad call.

When all departments in the company are aligned with the product vision, that supports the company goals, and processes are in place to include ALL the stakeholders interests, that’s where the magic happens!

Time is always a Billion dollar opportunity

time

The old expression “Time is money” is true. Time is the only thing every person have about equal amounts of in this world and that’s why we get so frustrated when we are wasting it on something. Turned the other way around it’s also a master unique selling point for entrepreneurs.

Lew Cirne the founder New relic, also founded a company called Wily, built to make the programming language Java self diagnostic while running. This is pretty standard stuff these days but not when Cirne started. The product became a massive success, and why? The software saved hours of waiting and troubleshooting. As Cirne puts it “Good software doesn’t waste users’ precious time, and makes those hours spent in front of the screen more pleasant and more productive.” If you haven’t listened to his session on the Stanford Entrepreneurial Thought Leader series, do that.

Another good example is Spotify. When they launched there was already free music available online, via bittorrent and MP3 sites. What Spotify did was to make it a more convenient experience by offering you to instantly find and play a song, with a few clicks. Suddenly there was no need to surf endless sites cluttered with porn ads to find the best version of a favourite song, and then wait for it to download before you could listen to it.

Our time is most valuable when we feel we have little of it. We want to have time for both family and work, need to travel far or just to manage many projects at once. TechnologyAdvice.com is a company specialized in saving time for companies by helping them choose the right software platform for their infrastructure. Pricerunner and other price comparison sites focus on getting the best comparison on products, saving you hours of time to browse the web for reviews and information.

There are countless other companies that optimise for time. Google being the closest to mind spent the better part of their business getting the one thing you are looking before your eyes in a flash.

To save people time or make the time they spend valuable is an amazing opportunity to grow a really successful business.

The foolproof way to prioritise tasks in agile development

agile_impact_matrix
Which is the most important task to work on right now? When working in an agile environment, this needs to be crystal clear to everybody involved. Is it a newly discovered priority 1 bug or maybe the most critical feature for this sprint? Who decides? The product manager, the team or the stakeholder that shouts the most? I’ve seen it all in many organisations and then only way to get around it really is to agree on a way to measure what’s critical.

The impact matrix is one of many ways to prioritise among user stories, bugs and minor features and to me it’s close to foolproof. Why? Because any way you use this, it will make a big impact for your product and it’s also really easy to use.

Just ask these two questions for every task: “How many of our users will this affect?” and “How often will the average user benefit from it?” Then use the scales and place your task in one of the squares. Top right tasks are high priority!

You can do this during sprint planning or in the middle of a sprint. It doesn’t matter, because the answer should always be the same.
Here is a Google Doc with the matrix ready for you to use today!
https://docs.google.com/spreadsheet/ccc?key=0Ai4ooumOasgddF9kY3hkS1F3ai05REwwNDdZRWl5R3c&usp=sharing

For most tasks it will be easy to use it, and for some cases harder. For example: If you’re looking to build a tracking-feature that will allow marketing to acquire ten times as many users as before, this needs to be measured on that scale. Not that it’s 4 people at marketing using a feature often.

This is not my invention, but unfortunately I have lost the source (a blog post). If you know it’s origin, please notify me and I’ll add it. Also I’d like to test this on non tech work too, as it could be used in any department. Let me know if you’ll try it!

3 key reasons to why User retention is your most important metric

Cohort-Created-To-Signup-Problem_thumb

What’s Your most important Key Performance Indicator (KPI)? New users? Sales per day? Website visitors? I would argue that they are all secondary to User Retention, i.e. retaining users and make to come back after one day, one week and one month. Here’s why:

  1. User retention is the most accurate metrics to show that people like your product or service. As Nir Eyal puts it in his great book “Hooked”; You want to help your users develop a habit of using your product.  The higher retention you have in the long run, the happier your users are and the more likely they are to recommend your product to a friend.
  2. Forget about new users for a second. It’s nice to see growth, but it’s worthless without people coming back. If less than 30% of your users are coming back one week after signing up or less than 20% of them are coming back after one month, then stop spending money on marketing and social media posts. Your funnel is leaking and you need to fix it. These numbers are of course different if you are selling cars on a website, then if you are trying to get people on board a new social network, but it’s a good ballpark figure.
  3. Sales and user retention are closely correlated. The more people are getting involved with your brand and your product, the more likely they are to buy something. If you constantly get them to come back to experience something new, reward them for their progress and create a habit, your sales will come.

So how do you do it? Make sure to set up proper cohort analysis of daily new users and track their 2nd day, 2nd week and 2nd month retention. How you define retention is up to you. In it’s basic form it’s just people coming back and opening an app or visiting a webpage. You could also tie it to some key product actions like logins or posting some user generated content.

Google Analytics can’t do cohort analysis (as far as I know), so I recommend you use a service like Mixpanel or Localytics.

Product managers need the User Pain Story

pain
You are not building a product. No, you are not.
You are not building a service. No, that’s not what you do.

So what do you? You are helping another human being to be really great at something! (I’ve touched on the subject before) I’v been planning to write this post for a while, and now I will dig into practical advice on how to maintain true customer centric product development, and how to explore: “purpose”.

This is no revolutionary new idea, but it is really hard to do. In my experience a company has a Product manager or Creative director that is responsible for knowing what kind of features the software developers should be working on, based on customer needs (hopefully). It’s usually the features that is the main topic of discussion at the company meetings – how they should work and what constraints we need to consider (yeah, we do it at Osom too). Nothing wrong with that, except when the features loose touch of purpose.

So how can we make sure all product development is actually making the user kick ass at something?

The Scrum methodology deals with purpose somewhat by stating a user story with a clear business reason. The user story is usually described like “As a X, I want to accomplish Y, with business reason Z”.
Example: As a customer I want to list all my previous orders so I can print them for my accountant. This story is fine and the featured needed is fairly easy to estimate by a dev. The problem here is that it mostly describes activity and not purpose. We need another layer before this that evaluates that this is actually the best way to solve the customers problem.

Introducing: the User Pain Story

The User Pain Story: My accountant hates me because he has to wait for me every month to get a summary of our expenses and I don’t have the time to give it to him.

Suddenly there are lots of ways we can solve this pain story! We could get the accountant access to the previous orders listing or send him an automated monthly email with all the information he needs.

The pain stories are crucial to being a product manager. You don’t need to discuss pain stories in company wide meetings but you need to reflect on them personally or within a small group of product managers. You should gather information by talking to customers, doing user testing and comparing your product with competitors. With this intel you can formalise the vision of the product and develop KPI’s that makes sense to monitor your progress. The pain stories will help you determine the best cure for a customer problem, from a range of options.

Hidden Pains

Note that pains are rarely expressed explicitly by a user. You need to dig deep to find what is bothering them. A root cause analysis can take you pretty far when you talk to a customer.

Watching a user using your product and listening to them is the best way to collect valuable intel.

  • The first impression lasts. What does your tool do for a first time user. Can they accomplish the most important task within X minutes without training?
  • What’s the users work environment like? Any bosses or clients that depend on the activity performed by the user?
  • What is the most important pain killer to a major customer problem and is it intuitive to see why your tool will be the best cure?
  • Is there a part of a common work process that takes a significant amount of time?
  • Is there a way your product will redefine how users work in their organisation?

The product development process

Most well designed tools come from a developer’s understanding of the user’s pain and she therefore accepts the reason why a feature is proposed by the product manager. By using the Pain story as an example you will get a solid feature foundation and more clear discussions around a feature.

  1. Find your method of collecting user pains
  2. Write them down and discuss in a small group
  3. Come up with 2 or 3 solutions to each pain. Pick one
  4. Use the pains to plan and validate your feature backlog
  5. Go build amazing tools that serves a purpose.

Why your USP has nothing to do with your product

Ok, you’ve built a product and now you’re trying to nail the product’s Unique Selling Proposition (USP) to create a compelling marketing message. Let me stop you right there.

The first mistake we do is to treat the USP as a product feature. It’s not. The USP is about the customer. It’s either what the customer can do (or as Kathy Sierra puts it; Kick ass at) or it is what the customer can identify with.

The classic USP-question is “Why should I buy from you instead of your competitors?” The easiest way to solve that is to put your self in your customer’s shoes.

How to kick ass

We have several internal drives or motivators that are the reason why we do what we do. I’ll leave it for other bloggers to elaborate on the various drives, but in designing a product or service you must have an idea what the person using it is doing and feeling.

A game for example, may satisfy many different drives at different stages. MMORPGs can satisfy the need to be social in a safe environment with other people that share a common interest. It also let’s you compete and overcome challenges which gives you a sense of purpose and fulfillment. By getting better at playing the game you overcome even more difficult challenges and are fed with new obstacles into a continuous feedback loop of challenge and achieve.

The basic design is to quickly be able to kick ass at something and then find a route to master in small steps. Instagram is a good example. Snap a picture and add a filter. “Wow, my picture looks awesome. I want to share this with my friends”. Then you play around with filters, maybe read up on basic iphone photography or import photos from your DSLR camera to Instagram to kick ass even further.

When designing your USP, highlight what the user can do, or even better what results she can achieve. Another important step here is to “be remarkable”. Your USP had better be something worthy of remark, or at least cause a raised eyebrow of interest.

  1. Five guys playing on one guitar is remarkable
  2. Five guys playing without a guitar is just another acapella song

Your new screwdriver is not “ten times stronger”. You can “cut the build time of your new kitchen in half and leave time to be with your kids” or “if you are left-handed, you can now do your carpentry without getting blisters in your hand”.

The benefit is a verb.

How to identify with something

Should I buy a watch from Breitling or Casio? That’s easy! It’s a matter if you are rich or poor! Right? Well, what about Rolex, Breitling or Omega? The price difference is there still but not as obvious. It comes down to who I am and how I see myself. So you look at your friends but also the brand advertising. The latest James Bond actor is the poster boy for Omega and some American celebrity millionaire is showing of a gold Rolex on another poster. Who of the two do you like best? Who do you identify yourself with.

The USP in this case is a way for your customers to find a connection or bond to your brand, business or product without having a clear verb on why something will make me do something better. Maybe I feel superior no matter which product I use. “Hey man, stop trying to sell me an Android phone. I’m an Apple fan!“. You didn’t compare your apple TV to other Internet connected digital media receivers. You were wow-ed by your friend’s iPhone two years ago. So, you just KNOW Apple produces superior products…

The definition of a USP for your brand are values that run through your entire marketing from the choice of people representing your brand, to the tone in your advertising and graphical presentation. It should be something that the customer can identity with, feel safe with and rely on.

If you are having trouble finding values, try defining what the customer should feel when she encounters your brand or product or what is the first sentence coming out of their mouth is

  • Playful – Let me try!
  • Comfortable – Yes, I found what I was looking for!
  • Nostalgic – No way!
  • Intrigued – What’s that?
  • Shocked – WTF!?
  • Inspired – Wow, look at that!
  • Relieved – Finally!
  • Creative – I bet I can control this with my iPhone

That’s it for now. I will do a dive into who the customer is in a later post. Please comment on this.