Build Your Product Quickly (ch. 8)

In our last installment, we talked about how to make sure your product is solving the right problem. That’s the first of three steps in finding your way to product-market fit. This installment, we’re talking about step two: building your product as quickly as possible.

In other words, it is time to talk about product development specifics. In this section, we’re going to start tackling the nitty gritty of getting work done in a tech startup.

There isn’t space in this short book to cover every kind of startup. To keep things simple, and because it’s what I know best, I will focus on software products, specifically Software as a Service (SaaS). But even if you’re building a hardware gadget, there are patterns and principles that you can apply from this section.

Defining the Work

The most important thing to get right is how you define the work that needs to be done. The past twenty-five years of software development has yielded some clear best practices. I will draw on those practices as a starting point, and extend our approach from there.

I am assuming you already have a good sense of your priorities because you have validated that you are, in fact, solving the right problem. We will come back to more finer-grained prioritization and decision-making below. For now, let’s keep it simple.

This is not a book about Agile development, per se. There are already plenty of those, some of which I reference in the bibliography. But it’s important we all get on the same page with basics before proceeding into advanced topics.

In Agile, we refer to a unit of work as a *user story*. For the rest of the book I will simply use the term “stories” to refer to these work items. A well-defined story starts with the user (or customer). It defines a specific goal the user is trying to accomplish with your software. The story is done when a user can realize some form of value by using the feature we are building. In other words, it is working properly and deployed to the web. A feature isn’t done until people are using it.

Stories work best when they are kept simple. They consist of a simple title sentence that summarizes goal for the user. They include visual assets that allow developers to understand the context of the story. And they include a set of testable criteria that ensure the story works as it should.

It is easy to go into too much detail writing user stories. This is especially true for product developers coming from an enterprise software background. Try not to get carried away with specifying requirements in exhaustive detail. Counter-intuitive as it may sound, it only leads to problems down the line. We’ll explore some of those problems later.

Tip: Don’t make user stories too detailed. Rely instead on frequent communication with the team.

For now, though, let’s define our stories as follows. “As a <user-type>, I want to <take-some-action>, so that I can <meet-some-need>.” We specify what type of user will be consuming this feature, what their goals are, and how we will know when that goal has been satisfied. A poorly written story is likely to create more confusion than it is worth. So, if you’re going to write stories at all, make sure they are simple, clear, and concise.

Next, the assets attached to the story should be as lightweight as possible. We do not need high-fidelity visual mock-ups for each and every story.

Again, it is tempting to go overboard with the detail here. Don’t just give your developer a high-fidelity mock-up and call it a user story. Mock-ups lie, both by misinformation and by omission. A hi-fi mock includes a large number of subtle and misleading assumptions. Unless a developer is very experienced, they may not push back on the assumptions depicted in the mock when they really should.

Thus, design mockups are imbued with an implicit authority they do not deserve. They imply that the design process is finished, when it rarely is. And they discourage conversation because the mocks look so final. Plus, because they are just a snapshot, they leave out important details about the behavior of elements on the screen.

Instead, use mock-ups only for depicting and discussing new ideas. Consider them temporary and disposable as actual work artifacts.

A style guide or design framework enables designers to provide quick hand-drawn sketches. This greatly improves communication and clarity on the team. Maybe black and white digital wire-frames are in order periodically. But keep the visuals as lightweight as possible. Use frequent conversation between design and engineering to adjust the details of the story as you build it. We’ll talk more about cross-functional teams below.

Tip: Avoid hi-fidelity mocks if possible. Use a design framework with quick sketches instead.

Lastly, a story should include a set of criteria that defines how we will know when it’s working. These can be things like data that should be modified after the user takes an action. Or a minimal set of components that must be present on a screen. Or an alert or email message that is sent to the user afterwards. Whatever these criteria are, they should be the testable with automation wherever possible.

Stories with a simple title, concise criteria, and basic visuals allow developers to build them quickly. Thus they reduce the likelihood of miscommunication and rework.

Experiments

The Lean Startup movement has enhanced our understanding of User Stories with product experiments. Agile user stories were originally specified by a product owner who (theoretically) had a feel for what the user wanted. In the case of startups that clarity is rarely the situation. Instead, startup product teams should be using experiments to learn what users want from the product as they build it. We discussed the value of experiments from a business perspective in Chapter 1. Let’s look at how we incorporate them into our stories.

An experiment in product, just as in science, should start with a well-formulated hypothesis. A hypothesis is a proposed statement about the world that we want to validate or invalidate by collecting data. For example, the following is a trivial but well-formed hypothesis. “We believe that making the ‘Buy Now’ button red will result in higher conversion rates. We will know this is true if conversion rates increase by 10% in a sample size of 1,000 or more conversions.”

I don’t want to get bogged down in the details of this example. There is plenty of resource material on experiments out there for you to read on your own. I just want you to think about your product definition in the form of hypotheses, and how that might affect the structure of your stories.

Tip: Include your hypotheses on your stories as a separate section after the title, visuals, and feature criteria.

Epics

Before moving on with our stories, let’s talk about epics. Some of your product ideas and experiments will be single stories, while others will be big concepts that must be made of lots of stories. These big concepts are often called epics. Think of them as containers for a set of stories that all go together. They will all be released to your users at the same time.

It’s best to document your epics in a separate place from your stories (more on that in the next section). Then you can have your stories link or refer to the epics of which they are a part. It’s possible, in fact, that your product experiments will be at the epic level, rather than the story level. That is perfectly fine.

Visualize the Work

You have defined the work as user stories. Next, you need to track what work is not yet started, what work is in progress, and what work is finished. You likely also need to follow whom on your team is working on what, whether that is together or separately. You do this by having some kind of visual control system for storing and displaying the work.

Why is this so important? Because work items in product development are physically invisible (see Reinertsen 2009). That makes it hard to see how much work you actually have, and where it is piling up. It’s equally hard to tell who on your team is overloaded, and who is underutilized. And, most importantly, it’s hard to see where high-priority tasks get stuck in your workflow.

By analogy, imagine you are in manufacturing. You can see all your raw inputs as they arrive at the factory. You have to track that material as inventory through the whole production process. In fact, you don’t get to declare it as profit until after it has been assembled and sold as a finished product. Until then, you are carrying it on your books as a cost.

As material works its way from one work station to another, you can see the piles of partially assembled product between stations. If there is a blockage in the flow of work, it becomes immediately obvious. You can change the process on the factory floor to optimize the flow around bottlenecks. Or you can add resources to increase flow through a particular bottleneck.

For software development, you have to be able to see all the work, and track where work is stuck in your process at any given time.

There are many ways to visualize the work. You can use a simple to-do list in a notebook or a complex task management software such as JIRA. A to-do list is probably too simple for our purposes. It is important that everyone see each other’s work, not just their own, and a to-do list will make that tricky. A tool like JIRA, on the other hand, is too complicated for a startup because you can get lost in all the features and configurations available to you.

My recommendation for startups is to start with a manual, physical system first. A whiteboard on the wall where the team works is usually ideal. If you must use a virtual system because some team members are remote, use the simplest system that will work.

Tip: Display your workflow on a board where everyone can see. Track the work as it flows through the process, not the tasks of individuals.

Kanban Systems

What I am describing is basically a Kanban system. The Kanban method (see Anderson 2010) teaches us the properties of a good visual control system. Here is how you get started.

First, diagram the current workflow from left to right as a series of columns on a board that the whole team can see (digital or physical). A column represents the “state” a work item is in, such as “Design” or “Testing”. The first column is usually something like “Ideas”, “Backlog”, or “To Do”. The last column is something like “Deployed”, “Validated”, or “Done”. You can have as many columns as you have in your workflow.

Second, use sticky notes (on a physical board) to represent the work items. Keep work items on the board at the same level of scale. In other words, don’t mix epics and stories. Use a separate board to track epics, and maybe even another for experiments.

Tip: Don’t mix epics and stories on the same Kanban board. Use two different boards.

Third, and this is really critical, track the date on each story when a work item first enters the board. Update it whenever it moves between columns, and when it lands in the completion column. This allows you to calculate your team’s cycle time. Cycle time is the elapsed time between when an item was started and when it was finished. This is your metric for everything else discussed in this chapter. You must use cycle time to measure improvement in the overall speed of your team.

Tip: If you don’t measure cycle time, you cannot see if your team is improving.

Remember, one of the key benefit of visualizing your team’s work is the ability to see where work is getting stuck in your process. For teams new to Agile or Kanban, there comes a surprising discovery. It is that the overwhelming majority of cycle time is accrued while work is waiting between steps.

These piles of work between steps are called queues. Queues are deadly to your business. Queues represent a ticking clock where partially completed work. You have invested time and energy in this work and it is just rotting away, unable to realize any value for you or the customer. It’s unsold inventory, unused capacity, perishable goods sitting in a warehouse going rancid. You need to find and eliminate the queues in your process. This is the single most important thing that is keeping your team from going really, really fast.

The best way to reduce queues in a system is by constraining the batch size (see Reinertsen 2009). A batch is the group of items that are handed from one team member to another between work steps. The larger the batch size, the more likely there will be miscommunication, rework, and lower quality output.

Let’s explore this with an example.

The team comes up with an epic for a new and exciting capability in the product. The theory is that this will attract a slew of new customers. In planning, the team breaks the epic into 12 stories.

The first part of the workflow for this team is design. The designer does the design specs for all dozen stories at once. They then hands them off to a developer to implement. That is a batch size of 12. This is a bad idea for several reasons. For one thing, the developer starts working on implementing the first story in code, while 11 stories sit accruing idle time. The designer can continue designing other features, but it’s pointless. The developer already has a queue 11 items deep sitting there. Any additional work the designer does is just adding to the developer’s queue, not moving things any faster through it.

But there is more than just time lost in a queue. Large batches also lengthen the feedback loop required for maintaining quality. Say there is an erroneous assumption in the design of the first story. The developer doesn’t see it until all dozen are handed over together. Only then is the developer able to point it out to the designer, who must now go and rework all 12 designs. The designer just duplicated an error in 11 more stories for no good reason.

The best way to reduce the batch size in a workflow is use Work In Process (WIP) limits (see Anderson 2010). A WIP limit is an agreement to limit the number of items being worked on a time. It is implemented by putting a number at the top of one of the columns on the Kanban board. This number is an explicit agreement by the team that this column is only ever allowed to hold up to that number of work items. It is an acknowledgement of the importance of small batch sizes.

For all this to work smoothly, one last rule is needed. Work can only be pulled by a team member from a left column, never pushed downstream to the right. Pushing would quickly violate our WIP limits, and it only increases our batch sizes. A team member who is free for new work can take something from the top of the column to the left and start working on it. They do not take anything else until they have finished that work item. The effect of this is a smooth continuous flow of work.

So, we have constructed a Kanban system for our team. Great!

There is something else happening here that is worth pointing out. We are beginning to enable a self-organizing team. We did so implicitly, rather than declaring it. And we did it simply by constructing a process that enables self-organization. Because our system is so clear and easy to use, there if very little need for external direction from managers. We’ll revisit this later, but I wanted to point it out here in this section where it first emerges.

Cross-Functional Teams

One way to reduce batch sizes is to build products as a cross-functional team. This is where your design, product, and engineering roles are working on the same small number of stories together. They can pair-program or just sit together at the same table. As long as the WIP limit applies to the whole team, and not individuals, you will end up with small batches.

Cross-functional teams create better products than teams organized into functional silos. The feedback loops are tighter, and so there is less rework and fewer miscommunications.

Trust me: Functional silos creep up on an organization, forming much earlier than we typically expect. I have seen startups as small as 5 or 6 people form functional silos. Business/product, design, and engineering tend to organically separate themselves by function. You have to work hard to counterbalance this tendency.

Tip: Have your product, design, and engineering folks sit together, and work on the same small number of stories together.

Optimizing for Space and Time

This brings us to the concept of trade-offs between space and time.

The ideal scenario situates everyone on the team together in the same physical workspace. Colocation is better for most startups than remote, distributed teams. Like cross-functional teams, proximity allows for a number of convenient optimizations. Many of these that we take for granted.

For one thing, the feedback loops are extremely tight. If the designer and developer are in the same room, a question about a design can be answered in a matter of minutes with a conversation. Sitting in different cities, that same conversation can be delayed hours or days. Video conferencing and chat programs (which I use exhaustively) cannot completely substitute for face-time.

A more subtle effect is also in play. Teams that work in the same physical place develop informal social bonds. These bonds are frequently undervalued by management and organization science. They form at lunch breaks or after hours. And they are extremely helpful in smoothing communication and resolving conflict.

You may think that five minutes huddled around a coworker’s screen to look at a stupid YouTube video has little to do with building product teams. But you would be wrong. You would miss the crucial fact that teams work best when there is trust. And that trust forms as much informally and socially as it does professionally in work contexts. Ignore this phenomenon at your peril.

Tip: Colocate your cross-functional product team wherever possible. If you are distributed, make time to get together in-person frequently.

Finally, a word about cost-conscious remote hiring. If you are based in an expensive metropolitan area where technical talent is priced dear, using remote teams will seem tempting. However, for all the reasons above, the hidden costs of remote work dwarf any slight gains from lower labor costs.

If you have to use team members that are far afield from one another, apply Conway’s Law.

Conway’s Law states: Organizations that create information systems tend to produce architectures that mirror the communication patterns of the organization.

Wow, that’s a mouthful! But think about it in terms of big companies. Teams produce components locally. Coordination between different teams tends to match the access patterns between the components themselves. This is a powerful idea!

Put another way, if you have to assign work remotely, assign a well-specified separate component. Make sure the component has a clearly understood interface to the rest of your system. Do not attempt to assign work remotely that is part of a cross-functional team. You will only be sad in the end.

Tip: If you must use remote teams, respect Conway’s Law

We have talked a lot about space. Let’s talk a bit about time.

Your workflow is now visualized on a board that everyone can see. If there are bottlenecks forming in your system, they become apparent immediately. Team members can swarm around an issue and resolve it quickly. This will improve your cycle time overall.

How often do you need to check in as a team? I recommend daily, weekly, and monthly or quarterly cadences.

Cross-functional, colocated teams should always have a daily stand-up meeting. The daily meeting is used to coordinate the basic workflow. They should also have a weekly planning meeting to review progress toward major epics or to review recent experiments. And they should have a monthly or quarterly business meeting for longer term goals.

A Different Kind of Daily Stand-up

The purpose of the daily stand-up meeting is to make sure everyone has what they need to get their work done for the day. If you have been in stand-ups before, you may have experienced a pattern. Each person in turn states what they did yesterday, what they’ll do today, and if they need help.

I want you to do your stand-ups differently.

Instead, huddle the team around the visual control board. Make the conversation about the work items on the board. Team members can still report if they need help. But the focus should be on moving items through to completion.

Why does this matter? Because utilization of individual team members is less important than throughput of the team.

Let me repeat that in plain English: Focusing on the productivity or utilization of your individual team members is a waste of your time. You have been taught that for your team to be efficient, everyone should be really busy all the time. That is wrong.

Your team is a complex system that includes cross-functional coordination. When everyone is loaded at or near full capacity, the system tends to build up queues. And when that happens, those queues can bring your throughput to a screeching halt. You have to keep some slack in your system in order to enable a smooth flow of work.

As such, it is far more important to focus on the flow of work than on the busy-ness of individual workers.

Tip: If everyone is busy all the time, queues will form in your system. If everyone is busy, these queues are extremely hard to dislodge.

Pulling it Together

Here is where we are so far. We learned how to define our work as user stories, including epics and experiments. We discussed how to design a work visualization system to track those stories through your workflow. We talked about the importance of colocated, cross-functional product teams. And we talked about cadences for planning and problem-solving the work. Do all these things, and you should be able to measure a dramatic improvement in your team’s throughput in a matter of weeks.

Enjoyed this chapter? Get the whole book on Amazon.

Originally published at www.startuppatternsbook.com on January 28, 2016.