Tell stories

It's supposed to be Cinderella, right?

It's supposed to be Cinderella, right?

If you want to hold someone’s attention you need to tell a good story. It’s true for bedtime stories with your kids, anecdotes in the pub, or a presentation in the office. So, if you want to get your point across – or just keep everyone from falling asleep – then make sure you follow the basic rules.

A story consists of a beginning, a middle and an end. (My boys cover this in 4th grade – it requires a lot of homework for some reason.)

In the beginning you set the scene, painting a picture of the current situation. Perhaps a girl is treated badly by her older sisters, forced to clean the house and cook while they go out partying. Perhaps your product operates within a certain business landscape and delivers value to a segment of the market.

Then in the middle something happens – a crisis, monster or inner struggle.. Perhaps a fairy helps the girl go to the palace ball but she has to leave before the prince can get her name.. Perhaps the market has changed and your product no longer delivers value, perhaps your segment is saturated or your competitors have out manouvered you?

Finally, there is the end. By this point the reader or audience should be looking to you to provide the conclusion – if you’ve constructed your story well there should be a sense of dissonance and an outcome should be expected. Perhaps the prince tried the slipper and it fits, the girl is saved from her horrible sisters! Perhaps your new strategy which focuses on strengths highlighted during the beginning will allow you to beat your competitor or deliver value to a new segment of the market.

The story should flow well and each section should support the overall theme. Is it a comedy, a tragedy, a fairy tale? Is it presenting a new product, a change in strategy or a new business direction?

Finally, and perhaps most importantly, is it a good story? Does it make you laugh, cry, or at least smile? Does it make you reflect on yourself, your business or your purpose? If it’s not compelling then perhaps you shouldn’t be telling it at all?


It’s only a strategy if it helps you make a decision

roundaboutI attended a strategic review on a particular product today. Unfortunately, it wasn’t very strategic.

Back in the day I was taught that a strategy is only a strategy if it helps you make decisions. The classic business example is the statement that our strategy is “to grow profitably.” Sounds nice but it doesn’t mean anything.

Let’s say you’re the sales guy trying close a deal or the sales manager who has to sign off the proposal. How do you price it? Well, what is more important – to get the customer or to make money? If our strategy is to grow then we need more customers – we price it keenly to make sure we close quickly. If our strategy is to be profitable then we price to make a good margin – but are happy to lose the more price-sensitive customers. If our strategy is to grow profitably, then we’re stuck – we cannot translate the strategy into a short term tactic.

The symptom then is indecision. A classic example is the team that considers three alternatives then decides to do all three. That’s not a decision, it just puts off the decision until later. Or how about the team that endlessly debates a proposal in open meetings as nobody wants to personally risk being wrong. Or in the case of today, a set of short-term tactics without anything to bind them together.

So then, here’s the plan guys:

  1. Set an objective. What do you do? What is the vision? (Not mission, that’s usually to increase shareholder value.)
  2. Select a strategy. At a high level you can choose price (if you want to be the cheap option); differentiation (to be perceived as better than the competition); or focus (pick segment or niche to dominate). For us in the Internet media business the price is free so you think laterally – the quantity or quality of adverts you stick on the page vs. the value of the content. You can put more ads on the page but that makes you the Walmart not the designer boutique.
  3. Define tactics. Now that you have a strategy that allows you to make decisions it should be easy to choose between the different options your product teams present. For example, reject feature A as it does not clearly differentiate your product from the competition.. or accept feature B as it provides a better experience for a small but important market segment.
  4. Set goals and plan. The tactics set the short term objectives – set milestones or goals and execute. Repeat.

For example you could decide you’re going to run a mobile news site. You decide to focus and select the segment of iPhone users. Tactically you decide to build an App and away you go. Instead of focus perhaps you decide on price and believe the best value is the quantity of articles. Tactically you aggregate as many free feeds as you can into a basic mobile site which can be accessed by most devices.

target_logoSo, on a side note, are we Walmart or the designer boutique? We’re probably Target right now. We roll out reasonable products for the mass market and make a basic margin. Some people prefer local suppliers but we have many loyal shoppers who visit regularly. If that’s our strategy then we just need to tidy up our execution – but stop kidding ourselves about being cutting edge..

Honestly though, we could probably pull off Macy’s if we were clearer about what we were trying to achieve in the first place. 😉

Code reviews

TenCommandments-50Back when I was an intern (well, the British equivalent) for a software consultancy I was taught how to develop software properly. I’d already figured out that I needed to design up front as I developed ever more complex software for my home computer – but some of the other techniques were less obvious.

Teleca was a small company where most of the engineers had come from large software consultancies. They made a profit by minimizing salaries and maximizing the rate they charged – just the same as any consultancy. To do this projects usually ran with a ratio of 2-3 junior to 1 senior engineers on each team. It’s a good model for software as a large amount of work involves filling in the details once somebody has designed the overall architecture and outlined the structure of the code.

But how to take these junior engineers and make sure they write quality code? If you’re going to charge them out at a hefty rate you want to make sure that they know what they’re doing, even if they’re not yet experts. Well, there were templates for functional specifications, technical specifications, we had design reviews, coding standards, unit tests, soak tests, regression tests, acceptance tests – the full set. It can be tedious but luckily we had strong team leads who made sure the processes were followed.

The problem was that the process only got us so far – we still had dumb code ending up in the system from inexperienced developers like myself.

The solution came in two parts. One was a serious bit of fun – the Teleca Commandments. I think it probably started out as 10 but ended up at 99. This was a mix of coding standards (e.g. thou shalt check parameters on entry to a method) and project standards (e.g. man shall not check in code that he has not tested) which were easier to remember than the slightly lofty coding standards. The other solution was the Friday afternoon code review.

A basic printed form was distributed – just the name of the reviewer, a list of the modules or files examined, and a box for any comments – and people in the office would exchange code with either a more senior member of their team or just another engineer in the office. The easy thing was to point out any basic violations of the Commandments.. I still can’t bring myself to use literals in code due to shame of having them pointed out by the reviewer every time. Just as easy to spot (but were occasionally justified) were so called code smells:  a method that is much too long or appears to do more than one thing; a class exposing some private data as a getter or as a parameter; two classes which appear to be working as one; poor defensive coding; overly clever algorithms, etc. The harder part was understanding why something was done the way it was – but here is the greatest opportunity for learning. Why did you make this method synchronous – is it a performance hit? Why did you open the database here – is it a security risk? Why is this a linked list? Why did you use malloc()/free() instead of a static buffer? I remember Ralph introducing me to ring buffers during one of these reviews – a technique that has always made me question how data is stored and aged in any system.

I’ve seen many different forms of code review since then – some teams review all check-ins, some teams review all changes once code hits production, but teams practice pair-programming and are peer reviewing constantly. The proximity of our code reviews to our Friday pub lunch was probably not chance. Regardless, my code improved dramatically as a result of this feedback – comments were never snarky, never mean, always well intentioned and delivered with an understanding that improving each engineer helped us improve as a company. In addition, think it helped remove the veil of secrecy that some engineers like to keep around their code – the idea that “my” code is somehow private.

So, if you want to quickly develop the coding skills of your more junior team members – or teach your old dogs some new tricks – at the same time as improving overall project quality then code reviews are the best way to do it. Start this week!

2 axis of product lifecycle

If you want to launch a new product you expect it to be innovative, yet stable. Inertia in your organization is the main reason this doesn’t work but this often doesn’t come from engineering..

Chart2Software development is a basic time vs. cost vs. features problem but usually we collapse time and cost into the (mythical) man-day. If we have a certain quantity of man-days and a set of functionality we want to implement we can visualize this as a chart. Let’s say we want to implement some kind of Finance app for the iPhone. We can place all of our effort on one device and get the best possible app we can.

Chart1Very nice, but you could argue with iPhone you can only reach a minority of users and with tens of thousands of apps in the App Store discoverability is a challenge. What if we just tried to get something running across as many mobile browsers as possible? We only have the same number of man days, so looks like features have to suffer. Perhaps now I can just check a stock price..

Is this acceptable? Looks like we’ve lost the edge with innovation – everyone has a stock checker 😉 Worse than that, perhaps our iPhone app looks like a Motorola website?

Chart3So, either we start small and then work up for specific devices, or we start big on a specific device and work down. Either way the inertia kicks in and our edges get almost no attention at all. It looks like stability in one direction is weighing down innovation in the other.

Ah. You can’t have everything.

This is the domain of product management. Do we understand why people like our product? What do they actually use it for? Who are are these people anyway?

Chart4Armed with this knowledge you can better plot that development course and the chances are that things were not as generic as you thought. You can pick specific features for particular segments – remember that a certain niche often has a certain device, e.g. Blackberry users like to manage a complete portfolio, however iPhone users check basic stocks and read news.

We often see this as a product races from that sketchy 1.0 to a stable 3.0:

1.0 – we had an idea, a good one, and we built something which gains some traction.
2.0 – we rush out something for a wider audience with all the features we think they need.
3.0 – plagued by poor quality we work to understand our users and release the first “proper” version.

You don’t always know up front what will work – sometimes you just need to throw it out and see what sticks, but remember that this inertia means if you try to do everything you will fail. Understand who you are designing for and your decisions will be much, much better.

Start low

If you try to support everything you think your customer might want, you end up giving away far too much for free.

You want it in pink? Sure!

You want it in pink? Sure!

We have a product which is customized for our customers. In this case the customers are mobile carriers and the customization is done as part of the delivery. I spent years selling trying to sell platforms to mobile carriers at much smaller companies and it was a nightmare. They asked for a completely customized implementations, their systems were incompatible (even with each other) and then there was change after change after change. If you think this is any different when you’re a big company you’re wrong – they still want those bullets pink with a gradient, and will refuse to launch if it’s not right aligned on the Motorola RAZR.

Previously, our solution was to make our product completely customizable through a configuration system. Every color, gradient, font or image could be configured and additional headers, footers or logos could be added liberally throughout the pages. The problem was it was never enough. You give your all, and the bullets still don’t have the damned gradient. All of a sudden any chance of profit from a deal has been wiped out by cycle after cycle of nit picking.

Stepping back, it’s clear that the real issue is with the deal itself – not the technical implementation.  Hey, doesn’t the customer want exactly what they asked for, yesterday, for free? At the heart of the negotiation are the people – trying to get the best deal for their company and it’s in their nature to always ask for more. I think my kids have this down to an art.

So, if you offer them a hundred possibilities for customization they think it’s reasonable to ask for ten extra things that weren’t on your list. It’s human nature. If you turn down all ten you’re going to look like the bad guy. Much better to offer them ten options in the first place then you don’t look so bad pushing back on that one extra feature they really, really want. If it comes to the crunch you can do it – but look at the difference. We offer them the top of the line customization system and we end up doing ten extras for free, while if we offer them a basic set we perhaps have to do just one.

Yes, you could argue that you may not even get to the negotiating table in the first place but I don’t buy it. If your product is good, as in, good enough that users want to spend money and/or attention on it then the carrier likely wants it enough to concede. Product not good enough? Maybe it’s not a product, it’s a feature.

Everyone likes creamed spinach, right?


A couple of weeks ago during what seemed like a regular presentation I was given an introduction to zero risk product design. It was terrifying and typical of attitudes in large companies.

The process begins by selecting a product which is stuck in a rut, in decline or generally in need of a face lift. Then follow four step procedure 467.B as per the company manual:

1. Ask our users what they think is important within the specific niche that the product occupies.

Yes, listen to users – but existing users will most likely say they are happy and perhaps ask for a few small features. If they hated the product they wouldn’t be an existing user.. The flip side is that in a niche already saturated with product users are not able to see past the existing “solution” for that niche.

2. Build an initial concept and show it to the users. Perform competitive analysis. Ask existing partners or buyers.

Getting feedback on mocks is always interesting, on an interactive mock even better. But, and it’s a big but, the benefit of this step is to confirm that you are solving a problem that the user has – in a way that is understandable by them. By definition, this is only truly useful if you are solving a new problem. You can incrementally improve your existing features all on your own.

Second, if you just copy your competitors you give nobody a reason to switch – and by the time you’ve implemented the feature it’s probably a year or two out of date.

Third, your existing partners are looking for no surprises – a product which slowly evolves and generates incremental revenue each year.

3. Based on feedback, iterate until most people are happy with the concept.

So you try to make everyone happy and build a working prototype which takes on board all the requirements. You run a focus group or a series of small trials. Your existing users ignore the new features, and hate what you’ve done with the layout. What do you do? Compromise? Well, we’ll keep the old layout, and colors, just add more tabs. And we’d better not change the ad placement.

4. Build final version and perform user trial on existing and new customers, fixing any usability issues.

So now it looks pretty much like the old version but users hate the tabs and can’t find their mail. Then what? Well, add some more help links and ship it.

ThaiCurryIt’s wrong and you know it. We try to make a Thai green curry yet end up with the same old creamed spinach.

Ooh, our existing customers didn’t ask for something spicy? The operational team is concerned about the exotic ingredients? Focus group says the new rice option is unappealing? Advertisers unsure about the impact of regional cuisine?

You make a product to improve the lives of those around you. Is that what we are doing? Do we trust ourselves, our engineers, our designers to deliver on this promise, with the understanding that they may fail? If so, then we control our own destiny and have the power to make a real difference. If not, are we investing in the wrong product? Do we have the right team? Are we a year too late?

Asking the difficult questions now will save us the time, money and, frankly, embarrassment of engaging in zero-risk product design. So go on, ask them..

Do we need code comments any more?

Picture 7Gah. I was looking at some code last week to figure out why a layout was broken in one of our services. There was no technical documentation and no comments in the source file. It’s not unusual in the world of software, but for me at least it makes it impossible to quickly figure out what’s going on. It’s not how I liked to write code, it’s certainly not how I was taught but lately I hear the argument that modern code is self-documenting. This thinking has its roots in the object orientated programming community and has been further reinforced by followers of the agile methodology. The basic idea is that comments are just more “code” that needs to be written, re-factored and maintained while well structured code is clear, syntax checked by compilers and functionally validated by unit tests. As such, inserting dirty, unstructured text into pure, elegant code is a sign of a weak developer, and/or bad code and should be frowned upon.

Continue reading