Building a great product

Naga IT Services
Filed under: Talk notes

A few weeks ago, the Austin and Wayne show (aka Austin Fagan @austin_fagan and Wayne Pringlewood @pringlewood) gave a talk called “Building a great product” for the July SUGSA event. Here are my brief notes.

They talked about Impact Mapping: a planning technique that brings back the focus to delivering business goals, not just software. It’s strategic planning, and it makes you think about metrics and measurable success criteria.

Austin and Wayne talked about their experiences facilitating impact mapping sessions, and how convincing people to try different approaches can be difficult. They recommend keeping the number of people in a session low, and not having too many passengers (people who aren’t actively contributing to the session, or directly involved with the project). They also said that doing impact mapping early is a good idea, and that there’s a strong connection between Impact Mapping and story mapping.

An Impact Map looks like this:

Why? > Who? > How? > What?

with a branch occurring at each question.

The Why? is the goal. It helps to keep it tied to a financial gain. Have one per impact map.

The Who? is the actors: this can be a project, an organisation, or people.

The How? is the most important bit, and the hardest. Make sure that you identify the behaviour that needs to change.

The What? is the the part that we usually, mistakenly, focus on. As a software development team, it can be easy to think that the way to achieve the goal will always be with more coding, but this isn’t always the case.

The talk was followed by a hands-on section where we split into groups of five and ran through a very quick, minimal, impact mapping session with a made-up example. This was a really great way to end the session, and was a great illustration of how powerful impact mapping can be, and how complex and brain-bending.

Digital Adaptation

Naga IT Services
Filed under: Reading

A little while ago, I read Digital Adaptation by Paul Boag. It’s a great read, and has lots of good advice that can be applied more broadly that just switching to digital. Throughout the book, Paul echoes (another great read) Mike Monterio’s Design is a Job, saying of management and clients that “it is your job to educate them.”

He talks about how the challenges of digital are only solved by long term solutions, deep collaboration, and change (especially at an organisational level). The way he talks about digital reminds me of agile principles: there’s a strong emphasis on collaboration and flexibility.


Change and change management are discussed throughout the book. It’s important to have a clear direction, even if you have to extract them from unclear business objectives. A good, clear, strategy is important for this. Without it, you react as things occur, switching contexts rapidly, and lose the focus you need to be productive. There’s lots more detail about this in Good Strategy/Bad Strategy: The Difference and Why it Matters by Richard Rumelt.

A good strategy should have three components:

  • A diagnosis.
  • Guiding principles.
  • Coherent actions.

I really enjoyed the book’s discussion around principles instead of rules. One of the ideas is that they should encourage debate. Principles provide a constraint to work with, but because they’re not finely detailed rules, there’s room for growth and evolution of the strategy.

Break down the silos

The silos and other divisions that exist in business prevent the people on projects from delivering their best work.

I think this is really powerful. It’s in our best interests to have more crossover between teams, and to make the divisions between them less solid. We should be moving towards more cross-functional teams, who sit and work together, made up of people from multiple departments. Regularly shifting office space around can be a good way to mix things up.


Another thread that ran through the book was the importance of innovation, and having time and support to conduct experiments.

Paul talks about how too much of a focus on efficiency, timesheets, and deliverables makes people aim for those targets rather than the best solution to a problem. Having the freedom to innovate makes people happier and more productive, because you’re investing in their personal development, knowledge, and expertise; it also allows for continuous professional development.

Part of innovation and experimentation is failure, of course. The important part is to learn from the failure, and share the experience so that others can avoid the same failure in the future.

Uncertainty, Software and Discovering Deliberately

Naga IT Services
Filed under: Talk notes

Last week, Cara Turner gave a talk about Uncertainty, Software and Discovering Deliberately for Cape Town SPIN. Her presentation was about how software development has a dramatic arc, and that the story there is in the uncertainty. Here are my notes from her talk.

Sometimes our thinking can get stuck and we can become locked into a bad script. The cost of change curve makes us want to full spec up front: big changes late in the process take a lot of time, and are very expensive. We need to remember that on agile projects, the curve flattens out quickly. With that in mind, it can help to delay decisions to the last responsible moment.

I think that this logic can be applied to a lot of project structures. On the full cycle of Discover > Plan > Sketch > Iterate on Prototype, Style, Design, Front-end code, it can be useful to get into code earlier rather than later. More on that later.

Learning is a big part of being a developer. In fact, it’s our biggest skill, and the iterative nature of agile feeds into that. Hope is the most dangerous word in software. It’s said when we have no control over, and no investment in, the outcome.


Impact mapping gives us a planning framework to answer some important questions, and focus on the goals, not just the features we need to develop. Why > Who > How > What. (Check out the “Building a great product” talk later this week for a detailed look at this.)

Story mapping can be useful to get the gist of the thing. We can get a feel for the scope, the users, and the team.

Innovation and experiments

Innovation exercises can be great, and energising, but most teams don’t do them regularly. This tends to be because we don’t have experience with it, so we’re not sure how to go about it. We should do these exercises because they can create possibilities: they can lead to experiments, where we can use an inspect and adapt feedback loop to learn a lot.

“Mobile” and “desktop” are just buckets

Naga IT Services
Filed under: Industry, Responsive

Even though most sites are moving away from the traditional silos of a mobile site and desktop site, towards one responsive site serving all devices, we’re still using a lot of legacy terminology, and I’m wondering if that can’t help but affect the way we think about the whole process.

We can keep using mobile and desktop as handy verbal shortcuts for small screens and large screens, but we need to be careful about thinking of them as fixed, solid, specifications. If we want to keep using these terms, we need to think of mobile and desktop as names of buckets, of general classifications for a range of devices.


Mobile can mean anything from a Nokia 5310 XpressMusic up to the latest Samsung Galaxy S5. The Nokia has a 240 x 320 pixels screen that’s 2.1 inches, whereas the S5 has a touchscreen with 1080 x 1920 pixels at 5.1 inches.

Mobile: an old Nokia phone and a new Samsung phone.


Desktop can be anything from an old desktop machine in an internet cafe running Windows XP and IE6, up to the latest iMac. The old internet cafe machine probably has a 14 inch CRT monitor, precariously balanced on a wobbly desk, whereas the iMac is 27 inches and probably sitting on a big, fancy, desk.

Desktop: an old machine and a new iMac.


Each of these devices, and all the ones between and around them, sit on a continuum. Screen size is just one of the dimensions that change the experience of using a device, but it’s the one we can understand most easily and show most obviously.

Other dimensions are CSS support, JavaScript support, input methods (touch and / or keyboard), hardware quality (how fast is the processor, how much memory does it have, and so on), age and quality of hardware. (There’s a whole other line of discussion around how Photoshop comps and mock-ups can only give us a point on one of these dimensions, but that’s for later.)

Different names for different things

I like to use t-shirt sizes when naming my breakpoints for a responsive site: S, M, L, XL. These are broad enough to cover wide sections of the continuum, and don’t use words that already have strong associations with existing tech. That means it’s good for developers and clients to stop them falling back in to old habits of putting things into silos.

Axure prototypes and Photoshop documents have their place, but we tend to do only two, at the far ends of the screen size continuum, and call them mobile and desktop. These deliverables are signposts for us to fill in the rest of the continuum. I think we need to move away from that, though. We need to steer ourselves and clients towards keeping in mind the whole continuum when we’re designing and developing. That’s why I prefer saying small screen and large screen rather than mobile and desktop.