Knocking Down Walls
One of the great things about startups is that they are so small that there’s almost no organizational structure to speak of. Basically everyone there is just trying to create something people want.
But as organizations grow, people start spending more of their time managing people and process rather than creating, and pretty soon you start specializing into typical functions of technology, product and marketing.
Unfortunately, a consequence of this organization is that often walls emerge between these groups. People often feel a closer affinity or allegiance to their group than they do to their actual product team they work on. Just take a look at who the people go to lunch with, or who they grab a beer with after work. If product managers generally hang out with other product managers, that’s a sign of the wall.
When the product managers and the developers aren’t on the same page, or they don’t understand what the other is trying to do, that’s a sign of the wall.
One of the things I like about Scrum is that it does quite a bit to break down these walls. But even with Scrum teams, sometimes the product manager isn’t the actual product owner, or he may technically be the product owner, but he’s not really engaged with his team.
There are other walls as well, such as between product and marketing, or between product and user experience, but the worst wall of all I would argue is between product and technology. It is almost impossible to accomplish something good when the development team and the product manager do not have an effective working relationship.
And to me an effective working relationship is based on a personal relationship.
Product discovery is the result of a true collaboration between product, user experience and technology, and that true collaboration depends on these relationships.
The simple act of moving the desk of the product manager to be next to the desks of the developers can have a dramatic impact. Soon they start going to lunch together, and playing foosball together, and finally sharing ideas together.
I’ve written earlier that teams that use their developers just for writing software are only getting about half the value out of their developers. If you want to get to that other half, it starts by building these relationships.
In my next article I’ll discuss another technique for knocking down these walls, as well as addressing several other common problems.