How we can build for our colleagues

It’s sometimes necessary for an organisation to develop software to support its internal operations. Doing this well is less straightforward than one might think. In this post, I examine some of the challenges faced by product teams building internal tools, and share some lessons learned from working on consumer products that are applicable in overcoming them.

 

The value that comes from using a tool is in how it improves a process. When an actor from a user story hacks around the current process to get their job done, it’s a good indicator that a new tool might be needed. Another step may be required in the workflow, for instance, if users frequently open another browser window to perform a particular task. There are also situations when a new feature is required for reasons other than improving the user experience. We may wish to gather data to train a machine learning algorithm which will ultimately allow us to automate a manual process.

 

Another reason to build our own tools is to avoid vendor lock-in – the situation where we become unable to switch our process from one product or service to another without substantial costs. However, it’s important to remember, that the decision to adopt any technology, be it proprietary or open source, is a long term commitment. While there are compelling reasons to choose an open source solution, we may incur large costs in adapting it to fit our process or in simply learning how to use it well if the base technology and expertise doesn’t already exist in our stack.

 

How do we avoid reinventing an existing tool which already fits our purpose? Cast a wide net to find out whether or not a cost-effective solution is already available on the market. Don’t hesitate to open this investigation to the operations and engineering teams. Their involvement is important; although they may have a good understanding of the problem domain, they often lack the marketplace visibility and exposure to product demos or sales-driven trials that product managers or the business team have. How have stakeholders solved similar problems at previous organisations? Getting input from every player at this stage can eliminate a lot of uncertainty around the necessity of the work involved.

 

When there’s a genuine need for a bespoke solution because the marketplace doesn’t offer an essential feature, expectations may still be high because users will be familiar with similar well established, high quality software. We can manage these expectations by including metrics and benchmarking on the product roadmap and by building them into the product as early as the size of the user base justifies the effort. This also gives us the confidence to abandon our developing solution for something better if it isn’t performing as we’d hoped. Involving users in the development cycle early can also help – users are more forgiving of work in progress when they are part of its inception and growth.

 

We can develop the best understanding of our customers’ pains by beginning the development cycle with an exploratory research phase. This allows us to get to the root of the problem and discourages us from rushing to a suboptimal solution. IDEO’s human centered design framework provides some useful techniques for doing this, such as by having customers map their journey through the process or by observing the journey directly, taking note of any unnecessary cognitive overhead and the behaviours of our “power users”.

 

The research phase may also take the form of a design sprint, where inexpensive prototype solutions are validated by observing how customers interact with them. Be sure to meet with every possible user at this stage. Not only will users at different levels in the workstream be concerned with different tasks; they may also have different working styles which the UX will need to accommodate. This can seem like a large upfront time investment, but it’s far less costly than waiting until after UAT to learn that the chosen solution doesn’t meet the customers’ needs.

 

What do we do when we don’t have the luxury of conducting a lengthy exploratory research phase? When pivoting, a startup or a product team needs to adapt its operations at short notice, sometimes resulting in the prioritisation of a completely new set of features. As an internal product team, our colleagues are our customers; we should therefore be well positioned to meet with them early and often. When we don’t, we develop false assumptions about where the process bottlenecks are. When gathering requirements, don’t be afraid of asking “why” too often. On first asking, our customers might tell us what they think we want to hear, suggesting “quick wins” or solutions they believe are easy to pull off, rather than revealing their greatest pains. Persistence in our questioning will pay dividends.

 

Feature requests are, in theory, better supported by an internal development team than an outsourced one, and straightforward for us to act on because we can easily seek clarification. In practice, we need to consider the long term costs of maintaining these features. Even simple estimation exercises like Josh Pigford’s build vs. buy calculator can be of help. More often than we’d like, resource constraints may mean that we’re not able to balance the local needs of our internal customer with the overall needs of the business. When that’s the case, it’s important for the health of the relationship to communicate why the work can’t be done at this time. Shared understanding and goals reduces the tension between the team and encourages us to review and update these priorities continuously.

 

If our tool doesn’t require expertise to operate, then we’re able to easily dog food our product across the organisation. This lets us find and form relationships with product-minded users who can identify problems which we may have become blind to when designing and building. Take advantage of this, remembering that the managers of most consumer products don’t have this luxury! Developing these relationships by holding “open office hours” increases the quality and quantity of feedback we receive.

 

Once the tool has been built, how do we ensure that product development continues smoothly? Having the development team focus early on the infrastructure necessary to support continuous delivery allows us to launch and begin gathering feedback as early as possible and keep a tight, iterative development cycle. when done well, we can reap the same benefits from practicing agile with our internal tool development as with our consumer products. MVPs are a great way to accelerate learning, but we shouldn’t be duped into thinking that it’s acceptable to produce sub-standard features, believing that they can be “improved incrementally” because we have only our colleagues’ expectations to manage. The launched product should consist of the minimum set of features required to deliver value, but each of those features needs to meet some previously agreed standards.

 

When planning, it’s important to be mindful of how our users will onboard. We’re familiar with the notion that “good design needs no instructions”, but even refined technical operational processes require some training. To save time and effort, training for our tools could take the form of a webinar which can be made available online for later access. Announcing the initial launch internally and continuing to meet frequently with customers can both help drive adoption, and announcing subsequent feature releases can help users imprint on workflows. Make all of the feedback received easily accessible to engineers, for example, through a dedicated Slack channel or integration. Above all, celebrate as a team when users are delighted.

 

In summary, it’s easy for us to become complacent or misguided when we’re designing for our colleagues. We know their organisation, its mission and its roadmap. We know their titles, respective roles and working environment. We may therefore assume that we know what’s best for them, and worse, we won’t make the time to validate those assumptions. Instead, if we do our internal customers the same courtesies as we would our flagship product users, but acknowledge when to treat them differently, we stand a much better chance of delivering the best possible outcome.

While working in the games industry in Japan, I attended a seminar about brainstorming. The instructor, professor Hidenori Satō, has written dozens of books on the subject. Unfortunately for many of us it seems his work has not been translated from Japanese, so here’s a brief introduction to his approach. I’ve translated the method he introduced to us as “Spark Ideas” (スパーク発想法). At the beginning of his seminar Prof. Satō led in with the following quote attributed to Thomas Edison: “Genius is one percent inspiration and ninety-nine percent perspiration”. I read this in two ways: first, even if you have ideas, they mean nothing if you don’t put in sufficient effort to realize them; second, you may have a sudden bright idea once in a while, but to generate ideas continuously, you need to make an active effort – and probably use a tool like the one I describe here.

The brainstorming process

Often we try to think of ideas directly from a theme. Unless you’re in a moment of “inspiration” this is hard. For the “perspiration” moments, we need hints, like the one Newton got from an apple falling from a tree. The best way of getting these hints is by changing the Point of View. And that’s all you need to remember! (*^ω^*)

Brainstorming process: Spark Ideas

Brainstorming process

 

You can think of the Spark method as a “cheat sheet” with a series of keywords to help you get started with your brainstorming.

Points of View for Spark Ideas

Prof. Satō lists up 5 basic Points of View (PoV) to get started with the exercise:

  1. State of affairs
  2. Point of view of the other
  3. Change character
  4. Change case
  5. Free of constraints

Working through these first five perspectives is usually enough, but there’s an extra list if you want to dig deeper:

  1. Triple ease
  2. Fun
  3. Positivation
  4. Indirection
  5. 3D expansion
  6. Similar case
  7. General case

I will describe all these points in detail later, but let’s jump first to how to do the exercise.

Brainstorming with the Spark Sheet

I recommend time-boxing the exercise. From experience, the “State of affairs” is usually the most important PoV, so expect to spend at least twice the time in that one as opposed to the others. If you need tons of ideas, you may want to attempt all 12 PoVs, though it may take too long. Even if you spend only 10 minutes per PoV, it will take at least 2 hours to finish.

If you are doing the exercise with enough people you may choose to divide them into groups. You could assign a couple of PoVs per group, with one group dedicated solely to “State of Affairs”.

Once you have allocated time, and appropriately divided people into groups, you just need paper or a whiteboard. Write the PoV and the theme on the top, and draw 3 columns. The first column are hints, that should come from the PoV. Write hints with as much detail as possible. The middle column will be for direct ideas, coming straight from the hints. These too should be as detailed as possible.

The third column is for ideas from association, things related to an idea from the middle column. These can be something that follows on in order from the initial idea, is the exact opposite of the idea, or just things that go together. It helps to have a cheat sheet with keywords on one side. Your sheet of paper will look like this:

 

Brainstorming example: Spark Sheet Pollution

Spark Sheet about Pollution

 

Keywords to get started

I’ve tried to select a few keywords for each PoV so you can get started.

(1) State of affairs

  1. Status
    1. Where are we at? Contents, outlook, flow, related work, schedule, place
    2. Domain, level, quantity, season, important factors
  2. Target
    1. Characteristics, functionality, structure, processes, elements, type
    2. Materials, size, weight, color, design, definition
  3. Self
    1. Company values, our technology, our resources, strengths & weaknesses
    2. Budget, available developers, external opportunities
  4. Main point
    1. Reason for it, difficulties
    2. Essential conditions

(2) PoV of the other

  1. Target user(s), as detailed as possible
    1. Adult A, kid B, high-school girl C, athlete, married person, old lady from the neighbourhood, a person with 2 dogs, etc.
  2. Requests/needs, correct & detailed
    1. Can we ask/have we asked users?
    2. Person status, surroundings, circumstance, specialty, personality, real thinking, new thinking, needs, values, requests, dissatisfaction, worries, likes, opinions, feeling, goals, and conditions.

(3) Change character

  1. Think of another person and write down their name.
  2. How would they do things?
    1. Way of thinking, behaviour, performance, personality, strengths
    2. Ask them directly whenever possible!
  3. Examples
    1. Close person: colleague, boss, junior staff, from another team, related, from same industry, family member, friend, someone with similar/opposite interests, acquaintance, neighbour, professor, student of a higher/lower grade
    2. Famous/historical: Buddha, Jesus, Bono, Björk, John Lennon, Messi, Trump, Picasso, Tom Daley, Tom Adeyoola, Tom Jones, Tom & Jerry
    3. Role model: an expert, specialist, experienced person, aficionado, protagonist of a story/tale

(4) Change case

  1. Think of the theme and target, and find a similar topic
  2. Write down the contents (status, method, conditions) in detail
  3. Examples
    1. Direct method (visual): picture the theme in a broader sense, and give an example from intuition. E.g. “reduce stock” → “reduce ingredients”
    2. Indirect method (logical): think of the essence of the theme, and from it give another example. E.g. “reduce stock” → “reduce unnecessary stuff” (essence) → “reduce flavour additives”
    3. Close example (change from same class): e.g. “sell cameras” → “sell computers”
    4. Far example (different class): e.g. “sell cameras” → “become famous” (sell brand)

(5) Free of constraints

  1. Ideal
    1. What is the state we want to be in? (in detail)
    2. What’s the ideal, the best situation?
    3. Write down the “ideals” as Hints, and how to realize/get close to those as Ideas.
  2. Break norms
    1. Try to break the rules: odd techniques, silly things, nonsensical, fancy, dream, insane, not common sense, innovation, daring
    2. Write down as Ideas the way you’d get there.

Extra PoVs

  1. Triple ease
    1. Low-hanging fruit: do easy things first
    2. Divide-and-conquer: divide in several parts, and assign to different people/teams
    3. Reduction: reduce the quantity or targets. Make our lives easier.
  2. Fun
    1. Make it fun or interesting; add hobbies; gamify
  3. Positivation
    1. turn upside-down; take the negatives and turn them into positives;
    2. find the positives and work on them
  4. Indirection
    1. Soften/cushion the blow;
    2. Make it indirect; mediation
  5. 3D Expansion: think of these 3 dimensions
    1. Space: expand the space, the area; change the place.
    2. Time: expand time. Think of the future and the past. Think in a longer span.
    3. Human: expand the human circle. Think of others. Get help from the crowd.
  6. Similar case
    1. Compare to similar cases
    2. Compare with cases that offer contrast
  7. General case
    1. Remove the particular case. Look at the forest, not at the tree.
    2. Think of the system

Rank the ideas

Once you’re done, you will end up with dozens of ideas. You may want to quickly eyeball the ones that lack detail or that are obviously flawed in some way and discard them to save time. Or you can focus on the ideas with many arrows coming to them. For the ideas you select to explore further, use a ranking mechanism, a simple example being the combination of impact and feasibility. For instance,

 

Theme: Do something about pollution — Best 3 ideas  Impact Feasibility Expectation (I×F) Rank
Bring leaflets to schools  2 4 8 2
Gather signatures in online petition about cigarettes 3 2 6 3
Create a game where each stage is about a pollutant 3 4 12 1

 

Hopefully your Spark Sheets will be sufficiently detailed that they will also help you to start producing a plan for those selected ideas.

 

Conclusion

Generating novel ideas from nothing is a big challenge to some of us but a bit of structure in a brainstorming session can make a huge difference.  If you’re stuck, try using a tool like this and be surprised at the volume of ideas your brains can produce. And as in so many other things, the more you practice the better you’ll get at it.

Most of the teams I’ve worked on have been not so great at breaking down the work that lands on the development backlog. There are plenty of resources out there on what stories are, and multiple different ways of writing them. There’s also articles written about different story splitting techniques. I couldn’t find anything out there about deliberately applying the theory however so I thought I’d write something.

Sometimes we just don't know how to begin breaking down work.

Before I dive in, lets start with some definitions

Epic – Also known as a “very big” story, that is unlikely to be completed in a single sprint or planning cycle. Would normally be broken down into several stories before being pulled onto a backlog. Epics can also be used for defining the main focus of a development team for a series of sprints.

Story – A smaller piece of work that can fit into a sprint or planning cycle specifically aimed at providing value to the end user and/or the customer. It can be good to apply the INVEST criteria to any story that you’re writing or at the very least include some acceptance criteria to define when a story is complete. Typically a story would be written in non-technical language to make it accessible for all interested parties to discuss. There are lots of different ways to write stories, Here’s a link to some sample formats.

Task – Pieces of a story that describe how the story is going to be achieved. These are usually written by the people doing the work. They should generally be short lived and completed within the sprint or planning cycle.

Splitting patterns

When examining a story (or an epic), you’re going to need to break it down. This has already been written about in much more detail over here. To keep things simple, I’ve summarized some of the commons ones:

  • Most difficult bit first (What’s the hardest piece of the story to solve?)
  • Simple case first (What’s the simple solution to the story?)
  • Functional first (Make it work, worry about performance later.)
  • User flow (What’s the first thing the user does. What’s after that?)
  • Per use case (What does user A want to achieve? User B?)
  • Per operation (buy a subscription, change a subscription, cancel a subscription)
  • Spike (What questions do you need to answer in order to know more about the solution?)

This is great! We now have some lines of thought we can use to think about our stories. We need to practice using these deliberately so as to get used to using them naturally and to ensure we don’t fall into the trap of using one or two of them over and over again.

Kata

Much in the same way as you’d practice different coding techniques in a coding kata, you can practice breaking down stories into tasks in a similar way. There is a little preparation to do in advance of your task break down kata.

Before you start, you’ll need to define some problems to split up. The problems should be large enough that they can be solved with multiple steps. Some examples might be:

  • Make a banana split
  • Go on holiday abroad
  • Buy something from an online store
  • Set up a new computer for a relative
  • Organize a party.

Try to work out if your problem is an epic or a story. If you’ve picked an epic, can you split it and write each story against the INVEST mnemonic? You want to end up with a few stories that can the broken down during the task break down kata.

Running the session

Split up in to groups of 2-3. Participants should be anyone that needs practice breaking down stories into tasks. If you can, try to make sure there is a mix of disciplines breaking down the selected story.

Choose a splitting pattern from above or from elsewhere, then take 10-15 minutes to apply the pattern to break down one of the stories. After you’ve applied the pattern, try to think around the edges and work out what was missed. What else needs to be included to make the story “complete”?

If you have lots of participants, compare and contrast results with other groups in the kata. Once you’re done you can try splitting the same problem again using a different pattern or use the same pattern on a different problem. Some problems will lend themselves better to one type of splitting pattern that others. Just keep practicing and you’ll get better at knowing which pattern to use for what kinds of problem.