Creating a product and innovation culture
Scenario 1
Marketing Manager: Can you please make the Product X for us?
Product Manager: No, we don’t have any space for this product in our roadmap this year!
Marketing Manager: But the data shows this is a big opportunity for us.
Product Manager: Sorry, we can’t help!
Scenario 2
Sales Department: If we add feature A to this Product, we think we close many deals and generate millions of dollars of extra revenue. When can we have this feature?
Product Manager: It takes 4 months for a team of 5 engineers and designers to build this feature! We will release it 6 months later.
8 months later, Product manager: We released feature A. Why didn’t we make those millions of dollars and we generate only a few hundred?
Sales Department: We had a wrong assumption about this part of the feature. Can we change it to …?
Product Manager: No, we don’t have time and resources anymore.
Scenario 3
Customer Success: One of our customers says we should change this functionality, otherwise they will leave our platform.
Product Manager: Sure we will add it in a month.
1 month later, Engineers: Why did the customer leave the platform despite us delivering what she asked for?
Product manager: Sorry! There was a misunderstanding. They were looking for a different solution.
Many of you might face problems like those in your workplace. You are not the only one to experience being part of a feature factory! The more technical and complicated your products are, the more chaos you will encounter with. But who is right in those scenarios? Should Product Managers ignore every feature request? Should the product teams work on features or products for months that might not deliver the promised value? Different companies try to fix these issues in different ways. Many companies are trying to be very strict on prioritization and only work on a couple of new experiments/ideas on the basis of confidence or value in a year. Of course, it’s good to have a strict prioritization system but it comes at the price of killing most of the new ideas which might be the growth driver of our products. Most importantly we create a culture that innovation and creativity are not welcome!
Recently at Plista, an ad tech company based in Berlin, we tried to solve this issue with a series of changes to create a product and innovation culture and it worked. Actually, it went very well. Within just three months, we could see the efficiency boosted, creativity and innovation became a priority, and everyone including company executives, intermediate managers, engineers, sales, customer success, and other departments are happy and satisfied with the outcome and even with their own job. Let me explain how we made it.
1- Get failed faster and cheaper
You will never be afraid of failure if you fail fast and cheaply. That’s why we changed our product development process to a discovery-first approach. It means we stopped building any clean, robust, high-performance products/features before validating the value and impact of it with a prototype. That prototype must be prepared and tested with actual customers/users within 2 weeks time. It’s very tricky and hard in the beginning to not fell into the trap of the old delivery team mindset, but with proper coaching, the team could learn in the product discovery phase, they are there only and only to test the idea is feasible, usable, viable and valuable. To learn more about Product Discovery, I highly recommend you to read Inspired, authored by Marty Cagan.
You might think it’s a stressful process but if you do the discovery right, you don’t need to over-work and everyone enjoy every day of working in the sprint.
One of the best moments I experienced in the past discovery sprints, is when the team finds out a usable and testable prototype is ready in such a short time. You can see how happy and proud the team members are with their quick achievement.
Of course, not always a discovery sprint for value validation is needed. Sometimes a simple experiment can help you to do the value validation way easier. I will share more about the Discovery Process and also Experimentation cycle in my next articles soon.
2- Work closely with customer-facing teams
Sometimes product teams are very far from customers. However, there are some departments like Customer Success, Sales, Integration Engineering and etc which are way closer to the customers. Some of them are talking to customers almost every day. Many product teams think they are very close to their stakeholders but in fact, they are not. If your product manager is the only one who talks to your stakeholders once a week, or you have a product demo with them once a month, you are very far from them. If the product engineers, rarely talk to the stakeholders, because the PO/PM wants to protect them and keep them focused then they are right not to understand the stakeholder’s concerns and mindset. During the discovery sprints, we assemble all relevant customer-facing stakeholders, engineers, and other members of the product team in one unified task force (max 8 to 9 people) and they will have daily meetings to share their feedback and fix any misunderstanding about the concept very quickly. We also exchange our opinions on how we want to design the test with real users, how reliable our prototype is, and what elements might impact the test results. In this way, engineers can quickly and wisely build a prototype that can be tested right in the final days of the sprint.
3- Get closer to the customers and users
In another hand, if we are a product team that is constantly building whatever our stakeholders and those customer-facing departments ask us to build, we are not necessarily doing a good job. It’s important to be close and listen to them, but it doesn’t mean the product engineers, designers, data analysts, and … are there to make the other departments happy. The product team exists to make the users happy and satisfied and when we are talking about users/customers, certainly we are not talking about every single one of them. Remember your stakeholder is not your customer, no matter how close they are with them. Not only the Product Manager but at least one of the engineers must attend in the direct call to the customers, sometimes maybe to just listen. That engineer might understand the technical problem the customer faces better. Also a software engineer or designer should understand why the user likes or doesn’t like our product. We should not make Product Managers the single point of failure in understanding the user pains or happiness about our product. The closer the product team members to the customers are, the higher the chance of innovating something meaningful is.
4- Involve engineers and designers with problems, not the solution
I remember most of the time, I see JIRA tickets in which someone asks how exactly they or their customers want the product team to build or change without mentioning what the problem is. Remember we hire product engineers, not coders! Engineers can answer what and how questions if they know why first! So we should make sure our engineers have enough context and it doesn’t matter, that context is not related to their day-to-day job. For example, if you are a campaign manager in an ad tech company and you are proposing a feature related to campaign targeting, it’s completely fine if you explain to an engineer how a campaign manager works and why do you target the users in a particular way. Maybe they can offer a simpler solution or even a solution might already exist to address this issue and you don’t need something new. Same goes for the designer. A product designer is not a Figma or Adobe expert only! Never downgrade the job of a Product Designer to just sketch what I have told you! Don’t ask them to design the solution, share your problem with them and let them find a user-friendly solution for that.
5- Create an open, transparent, and fair process for ideation and innovation
Innovation is not limited to one team, a startup founder, or just a creative manager. In every business, every team has a piece of knowledge. The company as a team can perform at its best when all teams get united behind innovation. At plista’s product and engineering department, we adapted Spotify’s Chapter and Squad model a few years ago. To build cross-functional team collaboration, recently we created a Guild for product innovations and asked everyone interested in Product ideation and innovation to join. People from completely different departments and backgrounds, from sales to customer support, product engineering to data engineering joined the guild. The innovation guild has regular forums. On those meetings people pitch their ideas and exchange their opinions. We also defined a transparent and standard process to choose which ideas can go to the discovery phase and which ones should be delayed or dropped. Without transparency, people stop contributing to ideation, get disappointed and lose trust. In the next articles, I will explain how we did conflict management and built that trust to make sure a healthy relationship and a focused aim on innovation exist in the guild.
6- Back the problems/ideas with data rather than biased assumptions
We created an idea template that every idea should follow that template. One of the key elements of this document is the hypothesis behind the idea. When we are bringing our idea, then we are accountable to share what metrics we want to improve, what is our potential revenue/value estimation, and how we came up with this assumption? We need to attach all data which backs our hypothesis. The product manager and the rest of the guild members can question the data when we pitch the idea. We are not looking for a strictly accurate estimation but we don’t expect anyone to just throw an idea without proper research to look for evidence. Ideas should not be based on feeling or just talking to one or two customers. Ideas can be attractive and deceptive. Do not attach with your own idea as it hasn’t been validated yet!
We don’t have a good or bad idea. No matter what the value estimation says, the idea does not have any value unless it’s proved by testing with the real users and that’s what we find out in the Product Discovery process.
In this article, I explained the 6 facts which are crucial to building a culture of Product and Innovation in your company. In the next article, I will share the 7 techniques which helped us a lot in coaching and paving the way for the transformation of the Product Team.
