While a strong Product Manager - Engineering relationship is essential for any high performing agile engineering team. There is another relationship just as important, if not more so:
The Product to Design relationship.
And do you know what third relationship in any agile engineering team separates the good from the great?
The Engineering to Design relationship.
We’re talking about a triangle of high productivity people, not a line.
The Product Manager should not hold the keys to Engineering and block the Designer from talking directly to Engineering. In reality, high functioning teams will facilitate the connection directly between Design and Engineering. In this way Engineering knows what cool stuff design is looking to build, and Design has a general idea of what is technically possible.
That is where embedded design comes in.
Embedded design is the idea that by incorporating a designer onto the agile team and giving them room to focus on just the scope of that team, they will have the needed level of attention to focus in on their area, support the delivery of new features that the engineering team is working on, and spend enough time thinking about the goalpost for the space of where we want to be going.
Here is a comparison:
Centralized design (the opposite of embedded): Design is a central resource
The good: A design center of excellence can easily be created. Designers have a strong sense of team, can easily learn from other designers and grow their skill set
The bad: Design can then feel siloed. The product manager could (if resource constraints exist, which they almost always do) will spend a considerable amount of their time advocating for design resourcing instead of talking to the customer and getting actual feedback. Additionally while it is not always the case, with centralized design you will have little to no consistency with which designer is working on which space. That means that while product and engineering have complete consistency and don’t have to deal with context switching (which can have an incredibly high cost), design will constantly need to be caught up, to be on-boarded to new ideas, and to hear customer feedback for themselves. All of this ladders up to a slow down in team throughput and a reduction in value delivered.
Embedded design is: Each space or scrum team is supported by a dedicated designer who attends basically all ceremonies and continues to update the team on what they are doing or what is slowing them down. This gives the best possible view for everyone on the team (product, engineering, design) into what everyone else is working on, speeding up delivery across the board.
The good: Design has no more context switching. They build a stronger rapport with the engineering team. They have the space to do longer term explorations in the space. They can still go back to other designers to get feedback. The designer gets immediate feedback from their product and engineering partners. In general they have a better sense of what is possible and what is not. They are more involved in general in customer feedback activities that the team is doing.
The bad: Sometimes with embedded design if there is no feedback loop with other designers, site spaces can start to diverge and have a slightly different look and feel. If the designer doesn’t jive well with the engineering team, they could have more of an isolated feel. While not always the case, embedded design can be more resource intensive requiring more headcount. I would counter argue here that if it is more efficient to staff for centralized design, you are more than likely under staffing your design team and would significantly benefit from proper staffing. Depending on the team, the work, or the designer, not all of them will want to attend every engineering ceremony. While missing some is OK, having design sit in on engineering meetings is essential for this to work. Some technical meetings won't be necessary for the designer, but oftentimes they are necessary to ensure everyone has context.
Do these sections seem biased? They are! Embedded design is the way to go. Let me know if you think differently.
Design should have an equal seat at the table with product, and engineering. Some people call this the triad model .
Here are the three key benefits I have personally seen teams experience from working or moving to an embedded design model from some form of centralized design.
1. Fast feedback loop / context
In technology, faster = better. You have seen a constant move in organizations that used to only be able to release new code once a month, to organizations making significant investment to move to micro-service based technology, and continuous deployment. It all ladders up to the same thing: The faster you can move, the faster you can react to the market, the customer, bugs, opportunities, etc.
So here are two scenarios that I have personally seen play out. Guess which one is centralized, and which one is the embedded design model:
Option A.
Design has a standing meeting every 2 weeks. During each one of these meetings, design has an elaborate unveiling of their highly polished and beautiful work they’ve done over the past two weeks. All of the interactions are there, they present the product manager with a fully working prototype, and are ready to get the prototype in front of customers for user testing.
UNFORTUNATELY, the button interaction the designer built out is based on XYZ data that we as the product team just don’t have the access to. Worse yet, to get access to that data, it would take 6 months for upstream services to provide it! Worst of all, without that data, the button interaction falls apart and we no longer meet the customer use case or job to be done we originally identified.
Well no biggie, design got some great learnings from the prototype, engineering has other stuff they could work on (even if this is by far our biggest opportunity). Design will go back to the drawing board with this great new information. Buckle in for our next meeting in 2 weeks! I’m sure we’ll have it right then!!
Two weeks later design again unveils iteration 2 of their incredible work. Again it looks magnificent. But the engineer SLAMS HIS HEAD INTO THE TABLE. It turns out the work on a past project was transitioned to a new designer who misunderstood the feedback from the last meeting. Whoops, this won't’ work either. Back to the drawing board and there goes another two weeks.
Option B.
At team stand-up, engineer A mentions that they are just about ready to pick up their next piece of work and it would be great to get mock-ups of what it would look like. After stand-up, the designer, knowing what the engineer was talking about takes learnings from a past user test and builds out a very quick bare-bones mock up. He slacks it to engineer A who lets him know that unfortunately the placement of these components are just not possible for XYZ reason. The designer knows exactly what the engineer means, makes the needed updates, and gets it over to the engineer by the end of the day. At the same time the engineer, seeing the rough first pass at design was able to start the back end work to pipe the required data through. By the time he gets the UX, he is just about ready to build out the front end. Two days later the work is complete and the feature is tested. Both UX, engineering, and design sit together to review user tests and actual data from an end customer live AB test. They as a team notice that people aren’t finding the next step in the flow as well as they should be. With a few small design tweaks, and a few basic UX changes, the team was able to get the user experience updated with a second more optimized version in a few more days.
Here you’ve got team B, which delivered not one but two iterations in about a week and has already gotten actual customer feedback compared to option A, where we are now in week 5 with no actual work started.
Sure this might be an exaggeration but it happens.
2. Throughput stability / Time savings: No time wasted boarding people to ideas
As seen in the comparison between options A and B, centralized resourcing can drive significant changes in throughput and team stability that result in time delays. If you’ve got a centralized pool of designers, any of whom can work on your space when their time frees up, how often do you think they change around?
Do you think each designer has their own flavor of design, collaboration, and values? You betcha. The same can be said for any product team, and any engineering team.
Design, if changed, would have no historic context on past technical limitations they had learned from past projects. They would also have significantly less context or be less in sync with the product manager and the longer term role / vision for the team.
And of course it goes the other way. Engineering would have less context for how the designer thinks or knowledge of what is coming down the pipeline. Product would have less ability to align the longer term roadmap to design goals.
All of this is solvable with embedded design. More context means greater and more consistent throughput. All of this time savings and lack of context switching means more value to the customer.
3. Time to think forward!
If centralized design basically means a designer works on a project for a product team, and once done goes back to the mothership to await the next design need, when then is non project based work ever going to get done?
Well Ben, why is non project work ever important? Projects are the lifeblood of an organization! Launching new features is what really matters.
Well across the board, especially with design, significant benefit comes from non project based work. The biggest benefit with design that I have seen is having the time to dedicate towards building a longer term goalpost.
What does this area look like in a year, three years, five years time?
What kind of cool stuff are we going to incorporate?
What kind of look and feel do we need to have?
Why is this important now? Because we are no longer living in a world of waterfall organizations. We can no longer, in good conscience, dedicate multiple teams’ time building out an end to end solution.Instead, we need to take baby steps, iterative improvements towards where we want to go.
Without a future vision how will we know where we want to go?
And without non project based time, how will we ever build a future vision?
Clearly, embedded design is the way to go. Having centralized design is like straddling agile software development. Unless you don’t have a design team, you cannot say you are truly agile until you have everyone sitting on the same team moving in the same direction.
What is stopping your organization from embedded design? Have you been in an organization that made the switch?
About the author:
Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do product management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want even more book recommendations?! Contact me!
Comentários