Start all of the pieces of work a little bit earlier. The key to starting work early is not succumbing to the pressure of having to finish the work. Don’t worry about finishing. If you’re a developer, you can start doing things while your design or information architect are working because a lot of your work actually isn’t dependent on their work. Some of it is, so you probably won’t be able to finish, but that shouldn’t stop you from starting.
Share Work-in-Progress Early and Often
When you share work-in-progress, share it with the caveat that no feedback is needed at this point. You’re simply sharing it to let people know where you are. For example, if you have to make 12 wireframes, share it when you finish 2 or 3. Rather than spending a whole week to drop 12 wireframes, share 2 – 3 wireframes every 2 days. The more often you do this, you start to build rhythm, and rhythm builds momentum.
When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.
However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.
If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong.
Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question.
And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question.