People talk a lot about “owning” a product, and that has several meanings. Ownership could mean responsibility for the process—being the individual whose butt is on the line if something goes wrong or if the product isn't delivered according to plan. That type of ownership focuses on results, and typically means the person will have to steer the ship in the right direction. Ownership could also mean being supportive and owning the ability of the team to deliver. It's a subtle difference, but it's one focused on mentorship and guidance, with the implicit belief that a good, happy team will reach the finish line with the right thing at the right time.
A third form of ownership refers to the features of the product or service itself. In this model, the “product owner” makes the decisions about the actual design. They have final approval on what gets built, and why it gets built. The expectation is that this person has more knowledge, more skill, and more vision than the rest of the team—and that they need to set a course for the product's vision, not only its execution.
The last model is often disparaged in business books. It's considered arrogant; consider the old adage, “There's no ‘I' in team.” But this last model works. Some people are more experienced, do have more refined skills, and do have vision and drive. When a project has a clearly articulated and competent leader, a team performs really, really well. It's fulfilling to follow a leader with a vision, and if you agree with the vision, it feels empowering. You have a reason to go to work.
If you are the leader of that group, it's exhilarating to have a team of people following you and believing in you, and that belief reinforces. It helps you double down on your decision with weird circular logic—“I can't be wrong because all of these people are following me—because they think I'm right...”
But this model has an important caveat: It doesn't work if the leader has a track record of being wrong. I once worked for a CEO who made promises he didn't keep, and when he asked me to work for him again at another company, I ran as fast as I could in the opposite direction—once bitten, twice shy. After watching him fail, I was much more aware of his negative leadership traits; I felt misled.
The autocratic vision also doesn't work if the leader isn't charismatic because people don't want to follow them. Decisions become full of friction, back-channel rumors weigh down the team, trust erodes, and people quit. It's hard to lead a team that doesn't exist.
Charisma is baked into a personality, but it also can be learned with experience. You can learn things like tone, language, and the appropriate place and time to make demands and give instructions.
You can learn from mistakes. For example, early on I let a conversation turn into a near-shouting match in a public space at work. I've never done that again because I learned to be aware of my tone of voice and the unproductive and downright-mean nature of such an interaction. I didn't have enough experience to know those things, and most young designers don't either.
Such situations are perhaps the biggest problem with the “lone leader” model. In many companies, a creative team member is handed a problem and told, “You need to own this.” They often hear, “You need to have a vision, know all the answers, and make sure everyone does what you say.” And that's a recipe for disaster. In consultancies, when senior creatives get promoted to associate creative director, their demeanor can change overnight. They feel a responsibility to be seen as strong, which often translates into being overbearing.
I just watched this happen to a member of my staff at my previous company. “Ted,” about four years into his career, demonstrated the same overbearing behavior when he received a small project to run and I told him he was the “project leader.” I chose those words to see how he would grow into the idea of leadership. On conference calls, he would mandate how things would be, and when people asked questions, he would shut them down. In critique, he didn't explain his decision-making; he proactively and loudly defended his decisions, rather than explain them. When he interacted with engineers, he treated them like hired help rather than team members. In all, he turned into someone he wasn't, and he wasn't fun to be around.
After a few weeks, I mentioned to Ted that I had seen his behavior change, and I asked why he was coming across as so defensive. He looked at me and said, “You said I was the leader. So I was trying to lead.”
Ted had seen leaders get results, and in the face of complexity, a seemingly quick path to results is to force them. But that approach ignores the complexity of a creative environment in which people have good ideas and don't like being told what to do. He assumed there was only one way to lead because he had seen only the outputs of leadership—success or failure.
But there are many ways to own a creative vision without adopting an autocratic style. One of the most important ways is to articulate a clear vision and direction, offer detailed and opinionated criticism during the concept development—and then, largely, let it go. I'll explain what I mean by “letting it go” through an example.
When I was the Vice President of Design at Blackboard, we launched the previously described product that helped college students find their way. I “led” the product; I articulated a very specific vision for why the product needed to exist, who would use it, how it would work, and how, generally, a student would experience it. I was able to articulate this vision in such detail because my team and I had been walking our way around the topic for years.
As the designers worked on it, we would critique it. We would discuss whether the design made sense in the context of the experience, and whether the design supported the value promise. I was very vocal in those conversations. I would probe and push on design decisions and constantly ask, “Why?” I would offer my opinion, typically framed as a statement—“That doesn't make sense, and here's why,” or “That will be confusing, and here's why.” I would stick my nose into whiteboard conversations, offer unsolicited suggestions, and generally, I was all over the designers.
Then we got to a stage where the concept became an articulated visual vision. We had something to look at and rally around. We had identified the roadmap: We knew what the product would do, how it would look, and how it would get built. We knew how someone would experience it. Our team now had a strong rationale for our design decisions.
At that point, my leadership shifted. Where I had been challenging the team, looking inwards, my role became to protect the team, looking outwards. During the detailed design work, product sprints, and execution, my focus was to remove obstacles and barriers so the team could do their work. I stayed somewhat involved with the vision and narrative because it's hard to stop advising when you see the product coming to life around you. But I didn't need to have the right answers; I didn't need to have any answers at all. I need to give the team room to come up with their own answers.
This is letting go—allowing the team to take ownership of an idea.
Takeaway: Treat project ownership as a strategic decision: know when to drive and when to step aside.