Improving Product Delivery with Deep-Dives and constraints

Daniel F Lopes
Paper Planes
Published in
3 min readAug 3, 2020

One of the biggest pains during the course of product development at Whitesmith was the constant iterations in features due to misalignment about the product’s spec, or due to new requests — about a feature or User Flow — in the middle of its development.

It would follow this pattern that you’re possibly familiar with:

  • Design team starts defining the feature’s UI and UX based on initial specs
  • The UI and UX is shown to the client for feedback
  • Iterations are made
  • Repeat above process infinitely, consequently loose control over the timeline and deplete team morale. (I’m possibly being a bit dramatic, but you get the point.)
  • The feature is implemented by the Development team and released to staging or production.
  • Realise the client has made new decisions regarding that feature, or that she was actually expecting a different behaviour.
  • Iterate infinitely again.
  • Plug the full team — yourself included — to ventilators and CPR machines. (Have I already mentioned I might being slightly dramatic?)

The team and client were never fully aligned. Problems may have started during spec definition — which was never revised, — and followed the team throughout UX, design, and implementation.

Besides this, the client made new decisions during the feature’s development without her realising the impact it would have on the product’s timeline and costs. Not her fault though — it’s our responsibility to take control of the process and warn for any potential consequences that these decisions have in the product.

(If you don’t work at a services company, you can assume the client to be any other stakeholder in your organization that you report to — from the CEO to the Marketing Department.)

Some simple changes in our process improved these considerably:

Deep-Dives

The first was the introduction of Deep Dives: a meeting to understand every single aspect of a feature or user flow.

In our case, it usually consists of the design team presenting the wireframes or mockups — based on the initial specs — to the client and the rest of the team. We go through every single aspect of the feature, with questions being made from everyone to everyone and:

  • The entire team clarifies what’s expected from this feature or user flow (regarding its business goals, design, behaviour, etc).
  • Notes about any necessary UI or UX changes are made.
  • The team gets in sync on what approach will be used for the feature or user flow.
  • The feature might pivot: some times during Deep-Dives we get to the conclusion the same goal can be achieved using a different but better approach.

When everything is clear, every decision made, and notes are taken, the team proceeds to another iteration (if necessary), or moves to its implementation.

As a consequence of these Deep Dives, we have noticed much fewer miss-expectations and miscommunication regarding a feature or user flow. All the team members and the client become more aligned.

Limiting the number of iterations

Another very important change in the process was to, from the very start of product work, define that the UI/UX of each feature or user flow will have only 2 iterations. (At least before it’s shown to the users.)

This makes the client and team conscious that all the decisions related to the feature have to be made inside this constraint.

This leads to more efficient iterations and Deep Dives: the team and client make a better effort to have more focused conversations, and to only discuss what’s relevant according to the product’s strategy. For example, feature ideas for the future, and changes that don’t have an impact on the current strategy (e.g.: OKRs), are immediately put aside.

The implementation of these two fairly simple changes resulted in a much better development pace, control of the timeline, control of the costs, and a happier team and client.

I’m Daniel, Product Manager at Whitesmith. Paper Planes is a place where I reflect on my experiences and learnings on the craft of Product Management, and where I share them with my team and community under the form of short blog posts.

If you enjoy these, please show your love by tapping the clap button!
You’re also welcome to follow me on
Medium or Twitter!

--

--

Daniel F Lopes
Paper Planes

Physics Eng turned into Product Manager, with deep interest in applied AI. // Product & Partner @whitesmithco 🚀, Co-founder & Radio DJ @radiobaixa 🎧.