Product Delivery – The one in the gap

Ever feel like you're a goalie? Just trying to keep the ball in play and not let anything bad happen? If so, welcome to Product Delivery! But there’s more to it than that.

While a goalie might make the headlines for a great save, we know we’re doing our best work when we’re largely unseen. The better we are in our role, the smoother things run.

That’s why the term “in the gap” is much better than “middleman”. A “middleman” is something you look to cut OUT of a supply chain. If you were to get your meats and vegetables directly from the growers, that would improve quality and speed- right? When Product Delivery is minimized, the exact OPPOSITE happens. 

 Product Delivery is that gap between “Grand Vision” and actual release. We’re here to help others find the shortest path to valuable output for the marketplace or users.  

  • How well defined do requirements need to be? 
  • Are they in that state now? Do we believe the team has internalized the goal? 
  • Are we going to get a product to Release in the time allotted?

 So, while it may seem like our job is like a goalie- protect the team, protect the release, etc. We’re also a Power Forward. Drive the ball downfield where those who are best equipped can make the score.

So, what does this look like in real life?

Some years ago the firm I worked for at the time had taken on a large marketing website that included integration with Salesforce. The ink wasn’t even dry when the director of development declared we would be over budget. When I asked why his only reply was “These kinds of projects always are.”

After some spirited discussion, we made a friendly wager on it.

What he failed to take into account was my personal involvement in overseeing the team leads and ensuring that the right people always had access to key client decision makers.

The next thing I did was break down the “wall” between design and development. No more “designing in a vacuum.” Our development lead spoke into the UX and UI designs BEFORE they went to internal reviews or before they went to the client. That way we could ensure that we not only met the client’s needs, but did so in a pre-planned way that reduced development load. By the time approved designs hit the development team, they knew what to expect and how they were going to get there. In some cases they were already half done!

The last thing I did was make sure that I understood the “why” behind the “what” of our client’s needs so when our internal leadership wanted to make “nice to have” changes, I could politely respond with “That’s nice, but it won’t add any actual value to their business because of the following reasons.” This vastly limited change of scope.

All of these things added up to team disciplines that were equipped to do their work quickly and efficiently. Was it seamless and smooth? Of course not, it’s software. We had a few bumps along the way, but having those small bumps early ensured we had no surprises at the end. An end that was on time and on budget. We crossed the finish line, and I couldn’t help, but feel like our team scored the end goal.