A Short Story on Why Clear Communication Matters in Product Development

2 years ago I was just hired by one of the corporate companies as a project manager. At that time there was an idea to create a website where the partner dealerships can list their offers (primary cars). This will become a consolidated place where people can see all the offers of the market, the prices of cars, monthly loan payments, etc. As the dev team was also new and previously mostly worked with agile practices, I was asked to help the business team to write user stories for our dev guys. I was considered a more tech-savvy guy. So, I became a project coordinator: a person who is responsible to deliver the business requirements to the dev team and deliver the website based on the initial estimations.

As a newly formed team, we delivered the first stage with an essential delay. There were a lot of reasons for the delay: the requirements were vague, we got a lot of change requests, the product was not based on customer validation, the team was not synced and mature, etc.

However, after the product release, we got some positive feedback that this tool brings transparency to the market, and clients use it as this is the only place where they can see the new car prices.

In parallel, the company was in the transformation stage trying to form a new digital agenda. During the new strategy formation, one of the pillars of the digital strategy was the development of digital ecosystems. So we were happy as our MVP of the marketplace was fully in line with this strategy. After some cooling period for the team, we started the next iteration of the product development!!

Iteration 2.0

Intro

On a strategy level, the company defined the understanding of the Auto Ecosystem. We formed a cross-functional team including digital marketing, UI/UX, Dev, QA, Business Dev, Back Office Operations, and Legal. With the understanding that this team is responsible for developing this product. In the next couple of weeks, the team formed the concept which was considered as a concept without alternatives. So, time to share it also with the business direction owner.

Concept Demo day

I was presenting the concept and how we came to this approach, what key problems we solve, and what should be expected results. All of a sudden, the business direction head said: “Guys, this is not what I want. I want a fully online experience. Here is my expected customer journey”.

At that time, it was a little bit of a surprise for me, as during these weeks we were also sharing our progress on some key issues, customer pain points, revealing solutions, and expected customer journey. However, trying to fix the situation, I said: “Ok, this is a good signal. That means we have an alternative concept also. Let’s do another iteration where we can compare these 2 competitive concepts as we should clearly understand what business goals we have and which one of these concepts will achieve that goal”. And all of a sudden one of the team members (from the same business direction) said: “We don’t care about the business goals. That is not important now. If he asks, then we should have such a journey. Why we don’t go through this new offered journey. In the end, he is a person who requested this new software”. This hit me and nearly knocked me out. This team member was fully involved in the process of the concept development, and never said anything about other options. I insisted: “Let’s not waste time: maybe this journey is better but it should be validated. Let’s do one more round in the coming days”.

After the meeting, the 1st issue in my mind was that we have a misperception of the product manager role: it seems that the business owner considers the role of the product manager the same as the project manager.

Concept struggle

In the next 2–3 days, I tried my best to objectively compare two journeys, trying to understand whether we missed anything or not. Again, research, some discussions with my manager, some advice from other product managers, … In the end, my manager and other members of the cross-functional team agreed that the concept we suggested is validated, and we should proceed with it. So a new round of the concept discussion. This time with the support of my manager, we were able to convince the auto lending business direction head that this is the best decision. By the end of the meeting, he said: “Ok. Do what you want. I just need this to be completed by your estimated deadline. No delays if we go with this concept”. I thought “ Hmmm…this is again a product of one man or not. In any case, the positive thing is that he understands that this is urgent, so we can come up with a 10x product”. In any case, a small win. We are motivated to start the development as we believe in what we are doing.

Development

The team actively started working. Despite a lot of the external stoppages, the team was able to develop the product as was expected. The FAQ that was used in our concept presentation was actually fully applicable for the release date. Wow! We thought we did a great job. So time to get customer journey and technology validation.

Formalities

We deployed the new website with all new functionalities. Again, presentations, demos to different stakeholders, dealerships, etc. So it is time for the business development team to finalize some key business formalities so we can start the validation in real life.

Again all of sudden, we find out that the business had not enough time to arrange these formalities. So we are stopped!! In the 1st week, I considered that this is just a tech issue; nothing systematic. But after 30 days :) I thought that the issue may be the fact that we have not defined a measurable business objective for business development.

Okay. Then let’s do it in a better way. I tried to introduce the OKR (objective and key results) concept where we have one business objective that was cascaded into 3 layers: business development, marketing/PR, and core team. It seems that this may work as we agreed on the key business objective. However, again, the business development team came back with 2 considerations in the next day:

• the OKRs on all cascaded levels should be approved by the business development team,
• more importantly, the objective we defined we may not achieve as we should just wait for the board to approve the papers, and we have no estimated arrival on that.

And one more thing: “Yes, we have an issue with getting approval. If you can push it forward, push it”. This highlighted 2 things: first, getting the validation is not a priority for the business development team; they don’t want to push it, taking the responsibility of going forward without this formality; and second, more important, I guess, we are not considered as a cross-functional team. The team just completed the project: the platform is ready; the remaining stuff is just business development as usual.

Outcome and my perception:

Ok. we have a very “good” product on concept and code level!!! We thought that this was a priority, as no delays were allowed if we were going with this concept. I was continuously working with the team that guys this is our chance to win the market and we should do our best to have the best time to market during this pandemic period. So what changed, where we missed and what went wrong. These were questions to be addressed and fixed.

MY LEARNING OUTCOMES SO FAR :)

1. Clearly define the role of PM. We missed agreeing on PM and Product Team Roles

People sometimes consider the PM as a project manager who delivers what is requested. Product managers are not project managers, although a little project management is needed to execute the role correctly. Project managers are responsible for the when. When will a project finish? Is everyone on track? Will we hit our deadline? Meanwhile, product managers are responsible for the why? Why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?

If you are a product manager then you should clearly define your role as a person who is responsible for the product full life-cycle, including the business goals. In reality, your key objective should be a measurable business objective.

In large non-agile companies, sometimes top management considers the unit/department heads as responsible to handle issues related to products/services; meanwhile, you should position yourself as a person who is responsible for that product. For instance, if in your product you have promotional material that conflicts with the company’s identity this question should not be addressed to the marketing or PR head, it should be directly addressed to the product manager.

2. Clearly define the boundaries of business owners. We missed to clearly communicate all the boundaries of the business direction and new product development.

• Before forming the cross-functional team, you should define the boundaries of the related business directions.
• Sometimes they think that they should “approve/accept/reject” solutions.
• Sometimes they consider themselves as requesters and the solution/product teams as vendors/service providers. So there is a wish list, and you should deliver them.
• Sometimes they don’t share the 10x approach of product development. They do their business as usual.

3. Form a cross-functional team with clear roles and shared incentives. We missed defining clear and measurable business objectives during the concept.

• Before forming the cross-functional team, you should clearly communicate to all team members that the team is the only owner of the product, and the team has the full power of making the decisions, taking the risks, and experimenting.
• Sometimes the team members have different KPIs. You should set up only OKR for the team and cascade it into the functional directions, so the team will have one shared objective.
• The team should clearly be communicated that they are responsible for the product's full-lifecycle and not only for the development. Sometimes they consider that further work should be done by business development and they should just provide services if needed.

As a product manager, how you should proceed: Your Resolution

I thought that I have 3 options:

1. Just give up: if the team is not synced and there is no shared vision, objective and understanding of roles, the best is not to waste the time. In this kind of org structure, product development could only work in internal efficiency-related products. For external products, the business direction always feels that there is no variance between digital and non-digital channels. So just work on internal efficiency products: there you may be more valuable.
2. Try once more: if you think that there is no competition and there is no urgency to validate your product, just wait. Maybe in the coming months eventually you will share the same objective. And of course, you can apply all your learning outcomes in the next iteration of your ecosystem product development phase. You already know all these 3 key rules: clear PM and team roles, clear business boundaries and OKRs,OKRs. Meanwhile, you can just work with them on a daily basis to support the product roll-out.
3. Ask Top management for help: if you think that this product is a high priority for the management, and in the coming months they will come to you with the question “where are we with the ecosystem formation”, then YOU SHOULD URGENTLY RAISE THIS ISSUE to be resolved. Just set up a round table with the key top management people who are responsible for your digital agenda. There you should only discuss 3 things:

• Product manager vs Project manager,
• Business Direction Ownership vs Business Development
• KPIs vs OKRs