How to create a closer engineering, product design, and product management collaboration
Or the story how we ended up using our own product instead
As with an every new job the first few months / half a year ( depending on the complexity or the size of organization) is dedicated to getting to know the position, understanding the processes and familiarizing with the company. I consider them an investment to the employee as it usually has a very steep personal learning curve rather than anything else. But after this period is over you become very eager to look for areas that could be improved. At least this is what happened to me. I am naturally very curious person and that in most cases is a good thing :)
Zendesk has a lot of offices all around the world, and as a product designer, I get to see early explorations and ideation for these projects all around the Zendesk. This, I think, is really amazing when you think about it. But what I have noticed was some offices did better than others in terms of engineering and product collaborations. Having product designers and product managers using resources from within the company can lead to a greater product development and better technological features. Unfortunately, this resource is not exploited enough. I felt my team needed to do better. So with a mission in mind, I decided to change this. As every idea has to be validated, I decided to start with the workshop which would help me to understand if my colleagues felt the same way.
One of the very interesting outcomes of this workshop:
Engineers, and designers seemed to work on the same products, but lived on totally different planets.
Meaning that we all use our tools of preference which hardly collide.
Being a designer I’m used to using tools that make my life easier (Sketch, Invision App, Zeplin, Illustrator, Evernote, Wake, Basecamp — just to name the few). And without even realizing I was certain that others will come and join me. After all, these are the tools designed to solve that specific task.
Outcome brought me to a reality, that more common ground needed to be found. And in the majority of the cases, this could be the software you develop.
“Why don’t we grow up and use our own products”
Suddenly it all made sense. We do have a product that we develop and that could be adjusted to satisfy the needs of feedback sharing and transparency in processes. But what’s more rewarding, with this idea we get to use what we build every single day. And every single day we can understand the product deeper, realize the problems and build empty towards our customers.
In later days, I found out that in software development using your own product is known as drinking your own champagne or as eating your own dog food. I have no idea why it’s called like that, but I bet it has some hilarious story behind it.
And boy I should have done this sooner. Few days in, I already noticed bugs and UX problems that needed immediate attention. I wouldn’t have discovered them if I wouldn’t have forced myself to integrate our product into my everyday processes.
Now, nearly half a year ago, since this project was initiated, I feel so thankful how it ended up. It became a habit to share new finding and new designs on our platform. Our internal community is thriving from the conversations around the problem discovery and around the design explorations involving all team members. Every single day I learn something new from our engineers about our product. I believe this process helps us to feel stronger empathy towards our customer who complain about one or another area. We feel them too. Every single day. It helps me to look forward to the future and drive the improvements from within.
Every single software company has a way to integrate their stuff into a daily workday. And I believe this is the biggest win.
Use your own products. Nourish them. Improve them from within. Every day.