[W]e should create designs and share them with peers and customers, consider their feedback, adjust and redesign, and repeat the process over and over again on the way to developing a whole product. We should build quickly but responsively. — Randy Hunt
I’m not here to argue against the “Ship Early, Ship Often” mantra. I wholeheartedly endorse the idea. Instead I’d like to chat briefly about something we seem to take for granted within these fast, iterative workflows: planning. Planning is the invisible element that drives a product along, noticed only in it’s absence. Planning mitigates roadblocks, focuses differing viewpoints, and provides helpful project boundaries for a team. Yet despite all that planning can do for us, it’s rarely spoken about.
Planning is the invisible element that drives a product along, noticed only in it’s absence.
The design team at Stack Exchange is an atypical design team. Whereas most product teams work in the same office, we’re spread out around the world. We work different hours in different environments. Yet despite our different circumstances, our challenges are similar to other product teams. We struggle to plan well, communicate effectively, and pro-actively keep team members abreast of project statuses. But these are challenges everyone faces. The inability to walk to someone’s desk adds even other wrinkles to the challenge. But whether you work in-house or remotely, you may find value in some of the lessons we are learning.
Planning takes time
Any movie worth watching is the end-product of years of planning and preparation. From scripts to storyboards, location scouting to costumes, numerous tasks must be accomplished before even the first scene is shot. You may only have one opportunity to bring everyone together in a location, so it’s of utmost importance that you have as much planned beforehand.
Planning for the Lord of the Rings began in 1997. Principle photography started in 1999. The first of the three movies was released in 2001. (Source: Wikipedia)
The lesson here is applicable to product teams: it may not take years, but planning does take time. A good project plan provides a vision, schedule, responsibility assignments, and task breakdown.
Recently the Stack Exchange Design team had a team summit, which I started planning about two weeks out. At the outset, this seemed like enough time. In some ways, it was. I got our schedule worked out. I had outlines for all our sessions. I even had a few workshops. However, in retrospect I could have made our time together even more valuable by disseminating project overview information prior to our summit. The better you plan, the more this helps a team understand a project’s scope and focus.
Empower team members
Not every team has a product manager, so you have to be realistic about your ability to plan a project. Planning can feel overwhelming. Leverage the power of your team by tapping into the different passions each person has showcased. Encourage them to lead portions of projects they’re excited about and will excel with.
Doing it yourself might seem easier, but it’s a great opportunity for others to invest in a project. Empowering team members also helps a project maintain momentum since they’ll run with the takeaway tasks. If you tackle every project in a silo, the burden of knowledge sharing a project falls entirely on you. This habit can allow details to fall through the cracks.
Beyond project responsibilities, empowering others can also mean simply keeping others informed. Knowledge is empowering. Share often and as thoroughly as needed. You don’t have to write a treatise with every update, but communicate regularly, over-communicate even, with your team.
Draw your red lines
Within politics the phrase “red line” refers to a point beyond which a party will not negotiate. They may be willing to give and take on some items, but on these items there is no budging. In the same way within product design, once you’ve agreed on a minimum viable product (MVP), be disciplined about maintaining your project’s ‘red line’.
Scope creep happens to the best of us. Just ‘one more thing’ can snowball a small project into a massively complex project. Combat this by using an iterative design approach to release small little items into your product. This will allow you to test your assumptions, gather feedback, and maintain project momentum.
In order to do this though, you’ll need to roughly map out your iterations. These aren’t set in stone. They’re waypoints on your journey of building a product as a team. Every next step in the journey gives you a chance to re-evaluate what you’ve done and where you’re going. Before you begin the next step, finalize its scope by identifying which small, manageable tasks you’ll work on within a release cycle.
It’s tempting to add along the way, but even small additions can have large repercussions. Saying ‘No’ to an idea today doesn’t mean you’re saying ‘No’ forever. Maybe it’ll be the next thing you’ll work on. Maybe you’ll get feedback during your current iteration that makes your new idea irrelevant. The point is to maintain your red lines. Keep your steps small. Publish, test, and iterate.
Keep working.
Product design is never finished. People are always changing, so our products need to adapt to their changing needs. Whether adapting to new circumstances, rethinking workflows, or adding new features; there’s never a lack of items to work. Everyday presents a new challenge.
Your browser does not support the video tag.
Keep yourself going by walking away from every meeting with someone with an actionable takeaway (and write it down!). Ideally you’re walking away from any team interaction with a list of items discussed, decisions made, and action items developed for future reference and to share with team members who weren’t part of that conversation. Remember, knowledge is empowering.
At a minimum though, communicate with your team the next steps you (and others) will be taking. This not only lets everyone stay abreast of the project’s status, keeping you from meeting twice about the same thing, but it also introduces accountability into team because responsibility has been assigned publicly. Everyone knows who’s responsible for what.