Customer-Driven Development at scale — A case study with Daniel Strazzulla, Research Manager at Contentful
We had the opportunity to chat with Daniel Strazzulla, Research Manager at Contentful. Daniel shared his experiences of iterating multiple times on team structure and process, helping his organisation become more customer-driven and uncovering the invisible channels that connect the product team to the rest of the organisation.
Sofia: Why don’t we start by talking about you? Tell me a little bit about what you do at Contentful.
Daniel: I’m currently a research manager here. I joined around two and a half years ago as the first actual “PM” hire. If I remember correctly product and engineering were around 15 people, with the distribution being one designer, one senior backend engineer also doing product work, me and a bunch of engineers. Now we’re close to 150 people, with around 60 in product and engineering. The product organization on its own has seven PM’s including myself because half the time I still work as a PM focused on strategy. We also have a dedicated research team and six people in design. We’ve grown a lot and pretty fast.
Contentful is a content infrastructure for developers to manage their content and deliver apps faster. Think about it as a very powerful headless CMS.
Sofia: What is it like to be evolving a product team in such a fast-paced environment?
Daniel: I think this is the fourth or fifth major redesign of our internal product development process. Like most companies, we hit a milestone every 10–20 people. Once you reach 30 people, things break so when we grew and pass different milestones we had to rethink how to execute and build product.
In the very early beginning we had a this theory called ‘fix the basics’. At the time we were hiring new talent focus on the user experience, we were constantly talking with customers so it was pretty easy to figure out what we had to do. Much of it was really ‘obvious’ and it kept us busy for a little while.
Also, we were acquiring our first clients and had a very close relationship with them. Then we grew more and more and that process broke. We started to make actual money, more money than we expected at that stage. We also started getting more feedback than we could actually process and this was when our second, maybe third development process iteration began. We moved away from just fixing the basics and trying to build a strong product strategy. In this iteration, we assumed we could use a tool that would enable us to link our product strategy with the feedback we were receiving. That sounded great on paper but it did not help us truly understand how we were going to use customer inputs and how that was going to impact the product strategy without being too reactive. Linking customer feedback directly into a roadmap does not provide the opportunity to think about the product in strategic ways and in the longer term.
We decided to step back and work more on the product strategy itself, to just focus on that and see how we could incorporate a process that would enable us to make the most out of customer feedback within a strategic framework.
What you want is a way to see the feedback in strategic ways, not only from customers but also from your internal teams. Having everything in one place can help but it has to have some structure to it otherwise it’s like putting everything into a drawer in your apartment — when you need something you spend way too much time tossing things around before you find it.
The real challenge for us at this stage was less about customer feedback and more about the fact that internal teams were being very reactive to things. You’d often hear, ‘Hey, this customer is screaming about this thing and then we got this Tweet about this thing’. Straight away, people tried to muscle their way into the product organization and scream, ‘Why are we not fixing this if we got three Tweets about this?’. We needed a way to let the teams know that we were listening to customers’ feedback but also to keep their expectations at a level where we could say ‘We cannot be running around in the forest like this, reacting to things like we did for the first year’. This was the right thing to do back then and but we are now in a different stage.
Solving this problem on a conversational basis was very difficult to do because we would go into a meeting and people would say, ‘Hey, my support agents talked with these people and these are our problems….’ This of course was not helpful because it would translate into a very isolated view of what the priorities were.
A better way was to give people the means to communicate feedback to the product team and see the bigger picture across the business. Doing this meant people could relax a bit which was great because it allowed the product team to focus on building great products while the rest of the organisation remained aligned around the strategy instead of becoming too focused on individual pieces of feedback.
Sofia: Could you tell us a bit more about how you helped multiple teams share feedback with the product team?
Daniel: In every organization there are always hidden channels of communication. For example, you bump into somebody in the kitchen and the person says, ‘Hey, you should fix this thing’. That feedback tends to be stored in people’s heads and that creates a false expectation that something is going to be done. People are disappointed as a result. These types of interactions, if not managed well, can result in teams not trusting one another which diminishes collaboration.
We spent a lot of time developing a proper understanding of how feedback moved through our organization and lived in our culture. We asked ourselves what the most effective ways to submit feedback were. Ultimately, we’re all working on it together so we need to make sure we’re all focused on the right things.
If you push for a different way of doing things maybe people won’t adopt it because they don’t think it works best for them. For example, if people like to submit feedback via Slack then you have to find a way to work with that instead of forcing unnecessary changes. There’s a reason why people share their thoughts with you in the kitchen. Maybe it’s is because they don’t trust the regular channels. I think it’s about having empathy with other teams. They are using their own tools and have different workloads and time constraints so if you make people fill in a form or whatever method you like, you may be adding more complexity to their workflow or discouraging their efforts to share useful data with you.
We spent time with lots of people in the organization, just talking and observing. You can think of it as a little ethnography study to figure out the situation. Then, after we had a clear view of how feedback was living and flowing, it was easier to come up with a way to streamline the process.
Sofia: Daniel, could you tell us a bit about your product org culture? Was it easy to implement change?
Daniel: We have very strong values around always learning here. We have a dedicated education budget. We invest a lot into making sure we’re up to date with the current trends or anything that can help us work better. We make sure our PM’s and the teams develop professionally. People are often very open to try new things and experiment in different areas of the business.
Having said that, we also learn to manage new knowledge better, this should be a no-brainer but you need to be wary about jumping in and implementing a change based on a blog post, a talk or some new training no matter how exciting it may be. Take a step back first, see what the real problems or challenges are in the team and compare that to what you just learned. There’s a good chance there will be a mismatch because what you want and what you need are often not the same thing.
Sofia: How do you lead change as a strategy and product leader?
There’s something I was taught in business school that stuck with me even though I don’t really like saying it. I learned that ‘you are your own brand’. It’s true. Everything you do speaks to your own brand. I take that seriously. In addition to the company values, there are a few things I try to practice all the time — being helpful, being honest, being professional. Most importantly, I focused on doing good stuff. I built a reputation for being someone who protects and demands quality.
I focused on embodying this culture of doing good stuff and that means I don’t have a lot of problems getting others to buy in. At some point your reputation speaks for you. I guess I have lead by example and that has worked for me.
Sofia: Can you tell us how you currently use EnjoyHQ?
Daniel: One of the biggest benefits of using EnjoyHQ is that we can look at our channels in more strategic ways. Not only can we see aggregations of what our customers are requesting, but we can also see that data in the context of sales for example. We linked EnjoyHQ to Salesforce and that helps us look at feedback from the top sales opportunities or recent lost or won deals. We can also look at internal thought leadership — things that people were submitting through Slack via Nombot or other channels like NPS responses, live chat and so on.
Looking at all this data in a segmented way helped us develop a holistic view of problems and opportunities across the board.
Another benefit has been around sourcing customers for deeper research. PM’s and designers often want to talk to users before releasing something. Finding specific customers to do this is super easy in EnjoyHQ which is pretty great. We can pick a customer segment, do a quick search about a specific topic and source a couple of customers to talk to. It’s super easy to do so we don’t have high barriers to continuous conversation with customers.
Sofia: What is your advice for product teams looking to align their teams around customers?
Daniel: I think one of the main points would be that to make it work you have to make sure you get enough people supporting your initiative. If you’re in a position where you don’t have a lot of influence across the board, you may find it a little frustrating. It’s important to understand that a project like this usually doesn’t fit on a roadmap. It doesn’t fit on a quarterly list of requirements and it doesn’t fit into your performance goals or your review. These types of transformations don’t happen naturally. You need to have a plan, rally your team around it and spend time to really understand how the changes will affect your business today and in the future.
It’s important not to underestimate the problem. You are introducing change and that takes time and consideration. Anything worth doing takes time so spend the time, test it out. That’s what we did and the only reason it worked out is because we tried in the past and failed. The second time we went beyond structuring our feedback. We actually ran workshops with designers and PM’s, making sure they can query stuff, making sure it’s useful and making sure the taxonomy is right. You cannot just get approval and then jump in, hoping it will transform the entire organization. Building customer-centric culture is not a hack.
If you liked this post then please give us a clap 👏🏻 so other people can find it too. If you’re interested in learning more about customer-driven development, visit us here https://getenjoyhq.com/
