Providing Vision To Keep Projects On Track

Problem

We have always had a mission and core values for the company centered around making data accessible for human beings, and our company does this through natural language generation. In the past, we did this for people and didn't allow them to do it for themselves, but we realized that if we truly wanted to meet our goal to make data accessible, we needed to provide the product as a software package. About two years ago, we started developing the new product, but we were continually missing the mark on what the product was going to do. We would do a bunch of development using two-week sprints, the features would come out, and then our product team would tell us that what we had developed wasn't what they were looking for.

Actions taken

There were multiple product owners involved because of the scale of the project, but it became clear to me that if you asked each of the product owners what we were trying to accomplish you would have gotten a different answer from each of them. We didn't have good clarity of what we were trying to accomplish or why it mattered. Everyone, including the executive team, had to take a big step back to define our vision for what the product was going to be in three to five years time - getting the software into the hands of people so they could benefit from it. We then had to determine the first five steps we needed to take to push towards that goal:

• It had to learn over time
• It had to be an intelligent system
• It had to be able to write English on its own rather than being template-based
• The data experience had to be clean and easy; and
• It needed to scale and perform.
  Once we had those five steps, we were able to bring things down to the product owner level to discuss design, and then deliver those requirements to our engineers. We revamped our entire process around this and made sure we started from the top when defining what our vision was. We were also careful to define it in language everyone could understand. It's easy to get caught up in jargony nonsense, where it's completely clear to the person who wrote it but when other people see it for the first time they will either interpret it in a completely different way or will not understand it at all. I realized that misunderstandings had caused a lot of conflict between our engineers and product team members was linked to the fact that nobody had a clear vision about what we were trying to do. Before the changes, they hadn't had a way to determine whether their work was aligned with our overall objectives for the product, so it was impossible for people to know who was right or wrong.

Lessons learned

Having shared objectives helped us to reduce conflict and improve our prioritization. We weren't perfect in terms of how we did this, and we faced a few bumps along the way. If I were to face this situation again, I would communicate our vision and the steps we were going to take much more. When you are a part of the team that is developing a vision and goals to support the vision, you don't necessarily recognize how many times people need to hear a message before it sinks in. We did a really bad job at reinforcing things. People would get lost along the way and we would have to bring them back and explain things again. Even if it becomes boring for you because you feel like you are constantly talking about the same things over and over again, the other person may have only heard about it once and may still be unclear.