A Better Product Development Process

P.S. You can read my latest article now: What Exactly Is a Product?

Two weeks ago, I sent out a poll asking what I should write about next. Your reply was deafening: ‘Organizing your product team’.

An interesting choice, my friends, and one that requires a disclaimer: In the world of open-ended topics, this one is king. So, I’m going to take an opinionated approach, sharing a way to go manage teams that’s served me well. I’ll also break this post into two parts: how to build your team (coming soon) and how to manage it (this one here).

I’ll assume you know a thing or two about Lean, Xtreme Programming, and/or SCRUM methodologies. These tactics, as opposed to the traditional waterfall method that aims to finish an entire product before releasing it, call for building products in shorter, smaller iteration cycles called sprints.

“Sprints are like flights; shorter = better.”

How short? In my experience, 1-week sprints for early stage startups are the way to go. Hardware startups, however, can be a different beast; you might want to aim for 2–4 week cycles. No matter the timing you tack onto, remember: sprints are like flights; shorter = better. The less lengthy your sprints are, the faster you can course correct.

Armed with sprints as your building blocks, you’ll likely be tempted to jump right into a kickoff session. Not so fast. You need to put a solid foundation of understanding in place first by holding an inception (see this post for more on inceptions). Once your team is aligned on the problem, solution, vision, and goals, you can get started.

Kickoff sprint planning meetings are like plot climaxes in novels; they’re where the action starts. Your first planning session might take 2–3 hours, but you should aim to get them down to 1-hour chunks of time. During these meetings, act as a facilitator, not a dictator. Since you’ve already aligned your team during the inception, they’ll easily come up with the sprint’s goals and tasks. This will help them feel empowered and thus, more engaged.

“Laying the groundwork for a successful product may be as inspiring as Kraft mac and cheese, but it’s undeniably important.”

Your job, as facilitator, is to break big projects into bite-sized pieces, help your team prioritize tasks, and make sure the end-of-sprint goal includes a working piece of something. That ‘something’ may do less than a dolphin participating in a checkers competition, but it’s something real and tangible. Your first few sprints, when you’re starting from scratch and have a colossal amount of core infrastructure to construct, may feel slow-going. But have patience with your team. Laying the groundwork for a successful product may be as inspiring as Kraft mac and cheese, but it’s undeniably important. Focus on what matters and work efficiently and before you know it, you’ll reach your ultimate goal: creating something of value to the user.

Let’s use an example to look at a sprint in action. Say you want to build a product that makes it easier for people to rent out their guest room. What required features do you think you’ll need?

Your mind probably churned up a list like this:

  • User Login (because hey, every website has this)
  • Search
  • Landing Page
  • Discovery Tools to Let Users See Cool Places
  • Dashboard for Hosts
  • Internal Messaging for Guest/Host Communication
  • User Profile Sites
  • Payments
  • Property Profile Sites, etc.

Quite the list! Though all these features brainstormed are useful, most are excessive. Strip away the bells and whistles, and you’ll see all that’s really needed to meet your goal is property profile sites and a way for guests to book rooms (Hello, vanila web form!). Gather a 2–3 person team and unleash them on these tasks. Completing these two items makes for a totally doable goal for a first sprint and it provides value — rooms can be booked. Just a little labor and bam! You’re up and running.

“Product leads are distraction umbrellas — they shelter their team from anything that may avert attention.”

Once the planning session is done, keep your team focused on the tasks agreed upon at the meeting. This means no working on other tasks and absolutely no other formal meetings during sprints. Product managers are distraction umbrellas — they shelter their team from anything that may avert attention. You can change your mind at the next planning meeting, but for this sprint you want to focus on your preset goals.

Think of your team as operating in open and closed modes. (Thanks to John Cleese of Monty Python fame for this!) During planning sessions the team is in the open mode; ideas, changes, etc. are welcome and encouraged. But once planning has ceased, your team tumbles head-first into closed mode. Everyone’s job becomes executing on the plan, and distractions of any kind make it impossible for your team to do so.

“Hold up!” I hear you saying. “What about bugs or other unforeseen problems?” I’ll let you in on a big secret about dealing with bugs: most of them don’t need to be fixed immediately. If your bug is terrifyingly, earth-shatteringly, product-killing bad, have your whole team stop working on the sprint goal and focus on fixing the bug. Otherwise record the bug, then wait until the next sprint meeting to prioritize its fix.

At the end of each sprint, tie up all your loose ends and present your work. This is done with a series of three short meetings.

The first meeting is a quick demo (~20 minutes). This meeting’s purpose is just like it sounds: teams demo the deliverables (product/features built, data gathered, user feedback from interviews, etc). Then, they gather feedback. Feedback can come from you and/or other stakeholders, but also think about inviting people from outside your team. Both folks from other departments like sales, marketing, etc., and and people like users, customers, etc. can provide fantastic fresh perspectives. Just make sure all feedback is constructive.

Feedback complete, have a short retrospective meeting (~30 minutes). Talk about how the sprint went for them team. What was great? What was boring or difficult? By gathering such info, you can make sure your team is constantly improving the way it works.

Last, hold a one-hour brainstorming session. With the whole team present, analyse results from the past sprint and re-align on problems, solutions, and goals. This helps your team keep overall goals top of mind and lets them integrate the ever-evolving data, knowledge, and progress that affects your product.

After all this, wash, rinse, and repeat — start a new sprint.

As you try this process out, remember: beginnings can be bumpy, and it may take a little time before your team can get going full speed. But eventually, your meetings will get quicker, your prioritizing easier, and your facilitator skills more fine-tuned. Then before you know it, you’ll be pushing out great new products and features so fast, people will swear you’ve discovered how to toy with time.

If you enjoyed reading this, please login and click “Recommend” below.
This will help to share the story with others.

Follow me @matthiaswagner

Thanks to Kavin Stewart, Kate Larsen, Drew Moxon, Tom Russo and Hannah Rothstein for helping with this.