You know what you want to do. You've done the buy vs build analysis and you've determined that it's worth building custom software. You defined the features, the product you need to deliver. You’re looking for a vendor to contract for those deliverables. Why, then, is Lab Zero sending you a proposal that includes people and roles you didn’t ask for?

The short answer is: we’ve been doing this long enough to know that most engagements are more successful when at least the designer, product manager and some developers have worked together under the same principles with a track record of results. When it comes to the interactions between these roles, the whole is more than the sum of the parts.

The Software PDE team

 

The brew of product, design and engineering can be downright magical at times, but the interactions along specific edges of the triangle shed some light on why this combination works so well.

Trust among Product and Engineering

Along this axis, the product manager is the guardian of the engineering team’s ability to deliver value efficiently. The product manager removes obstacles to the team, while deprioritizing anything that does not add value. 

At the same time, the product manager and tech team frequently negotiate technical debt up and down. PMs and engineering leads who have worked together know this is an exercise that requires trust and shared experience. Sometimes features have to be delivered along a specific path in order to realize customer value, while tech debt accumulates. And sometimes that tech debt has to be paid down in order to keep the foundation firm for new features. Without trust, this information can’t be communicated and acted upon reliably. (We discuss trust a lot at Lab Zero.)

Product managers who understand the frameworks used by engineering can help mediate technical decisions, particularly when those decisions involve technical stakeholders or owners of existing teams and systems. When those decisions have product implications (how fast can we change it, how scalable is it, how secure, etc). A good engineering lead who knows how far the PMs knowledge extends can break down a trade-off so that the PM can facilitate, document and defend the best possible decision.

Working agreements among Engineering and Design

An engineer and a designer have a lot to say about when the other has completed their job. Definition of ready (when is a story ready to be played) and definition of done (when is that story considered complete) are used every day at Lab Zero, and it works best when those definitions have been hammered out over time. Our engineers and designers wrote the playbook for DoR and DoD, so you can be sure they’re on the same page when it comes to hand-offs.

Our designers also understand the frameworks used by our engineers, so they know (for example) not to create ‘blue sky’ designs when an existing library of UI modules will be leveraged in the build. Lab Zero designers use tools like XD+Zeplin, or Figma to give developers the assets and styles they need with the greatest fidelity and the smallest chance of miscommunication. Developers are accustomed to having their work evaluated and accepted by a designer. A designer documents gaps between the design and the ‘as-built’ product. The whole team have a say in which of these gaps impact the product most, and the engineers work hard to bring them into spec.

We've spent a lot of time bridging the traditional gap between design and engineering, and it shows in the way we work together.

Collaboration among Design and Product

The design-product axis is all about discovering value. The two roles sync up on goals, they interview users together, and they present designs together to business and technical stakeholders. The product manager formulates a problem statement that, if solved, will unlock value for users. The designer develops solutions that they test and evaluate together. Designers alone on a project often get incomplete and conflicting feedback from many directions (because everybody has an opinion on visual design); when present, the product manager can buffer that input and make space for a designer to achieve the best outcome for the user. Together, the product manager and designer(s) can plan to ensure that designs are ready to make the best use of scarce engineering resources.

Shared objectives all around

When the team shares objectives they move forward together. Designers don’t just rotate in long enough to ‘shed’ a design; they stay with you and design the next feature or iteration while on call to build up designs for exception scenarios as the engineers encounter them in the current iteration. Engineers take a break from delivering stories to evaluate concepts and designs that are in the proposal stage, saving stakeholder and user testing time by eliminating infeasible alternatives at an early stage. The product manager maintains high visibility throughout the cycle to resolve blockers, break ties, and run interference for the team while the team delivers the sprint. (Read more about how we tackle the world's toughest software challenge.)

All this results in a strong cadence that delivers value sprint after sprint.

But but but

Sometimes we hear things like these when we propose a PDE team for an engagement.

Wouldn’t I save a lot of money if you just gave me the developers?

If our developers (or your developers) wait four extra weeks for you to produce a buildable design the first time (a very modest ramp-up time for a designer who is unfamiliar with the implementation details of a tech stack), then you’ve easily spent as much as your Lab Zero designer is going to cost you for the duration of the project. The developer time is the largest single expense on the monthly invoice, either way.

I have a Program Manager, and I don’t want them to be left out. Can’t we just use Brad as the PO? 

If you try to replace the Lab Zero product manager with a project manager or an inexperienced product manager, you’re going to spend some cycles delivering non-product (or re-delivering the same product), and if you grind the gears too much you might drop some developers on the road as you go–replacing burned-out developers in the middle of a project is time-consuming (and often expensive).

At our company, we use designers from a design pool. They rotate through projects. They’re pretty good, and we can save some money if we use them.

Chances are, we can use them. But here’s why we want at least one part-time Lab Zero designer on your project. Our developers, for their own efficiency, rely on our designers to look at design problems from the perspective of buildability and completeness–in addition to usability, meeting the needs of the user, being attractive and innovative, etc. Our designers have participated in the estimation process long enough to know what kinds of designs require more rounds of iteration with developer feedback, and which ones can go straight into an estimation session. In short, developers get more done with a Lab Zero designer because the designer works within realistic constraints. 

Your designers may be in high demand across your org, and people love designers because they help visualize ideas–and that’s a skill everybody appreciates. We’ve found that Lab Zero designers bring a level of leadership to value discovery that is usually missing in the skill set of a designer who is just hopping from project to project, dropping in designs and then leaving. Our designers are especially good at asking the questions that elicit a problem statement directly from the mouth of the user–a problem statement that is a better starting point for design, typically, than something like, ‘We need to nudge the user toward purchase at points A, B and C’.

I’d really like to manage the team myself.

Letting go is hard! Each time our client has found a way to wedge our product-shaped team into a slot that only had developers in it before, that person has been promoted and gone on to manage larger groups with bigger budgets. (We love to stay in touch with those clients!) Learning to manage to results is a key step in getting new challenges and new responsibilities. When we deploy a PDE team the first thing we do is establish the cadence of connecting with our primary business stakeholder. Through weekly sprint demos, design reviews and product check-ins, we keep you in the loop and make sure we’re generating as much value as possible.

At the end of the day we love working closely with our clients especially when the goal is to leave behind the practice and knowhow to continue effective product development practices. 

Conclusion

You weren’t expecting to see all these roles in the proposal you just got, but we put them there to make you successful. If you still have doubts, let’s talk so that we can understand your situation in more detail.