Nearly every start-up company goes through the same experience - the founders will start with a vision or idea that pivots over time as the product (hopefully) finds its market fit and is modified and adapted to the needs and requests of end users. While there are some cases where the concept initially presented in the pitch deck is the same product five years later, these are the exception, not the rule. Given that modern software technologies evolve quickly and require ever-evolving product adaptations, Software as a Service (SaaS) companies are particularly prone to this need for change.
When I joined Sauce Labs in 2014 I found myself in a typical Silicon Valley start-up - it was an engineering-driven company with a single large office for 70 employees located in the heart of SOMA, San Francisco. Since then, the company has grown to 300 employees with multiple offices around the globe. These operational changes have been accompanied by various cultural changes as new employees have joined the company. This can be challenging for engineering organizations as they work to maintain their focus on a technical product.
As the Sauce customer base expanded, so did the list of technical requirements. We needed to grow beyond offering browsers in the cloud for automated Selenium tests. The build out of the product roadmap required extensive hiring and re-organization. What had been a single engineering team working on a specific feature was now a dispersed, diverse group of people with different responsibilities including engineers, scrum masters, product management, sales engineering, product marketing, and more.
Photo by Annie Spratt (Unsplash)
Delegating certain product responsibilities to others allowed engineers to focus on their work, implementing new features and fixing bugs. This model can work for non-technical consumer products but can be problematic when building a product that is targeted to developers and other technical users. Problems arise as engineers become decoupled from the users of their product, and feedback loops go through multiple channels that are often narrated by a non-technical person. Product obsession can sometimes be lost in the shuffle when addressing existing customer requirements.
When engineers are not exposed to or engaged with customers, they lose the personal connection to the product as they don’t experience the excitement a customer shares if the product works well nor the frustration if it doesn’t. Often the desire to solve technical challenges gets prioritized over the actual usefulness to the end user. A relationship to the product has to be developed internally as well as externally otherwise features just appear to be boxes of value being thrown over an imaginary wall.
Modified picture of a sauceio.com blog post (see slide 24 of https://www.slideshare.net/ManueldelaPeaPea/testing-101-66597895)
While it is the responsibility of a product owner to build out the product vision, innovation can’t be driven by a product team alone. It needs support from an engineering perspective especially if the product is targeted to developers. Dogfooding is a very well known technique that can build such a product obsessed culture. A developer being passionate about his own product is a key ingredient for the healthy development of a technical vision and direct customer engagement plays an important role here as it helps engineers to identify themselves with what the company sells at the end of the day.
As an open source enthusiast and maintainer of various OSS projects I have always enjoyed connecting directly with customers on a daily basis. It has been the source of many ideas, some of which have become offerings on the Sauce Labs platform. This cycle of speaking to customers, feeling their pain, finding a solution, and building a product to solve it, has proven to be a simple but successful way to build up my own product obsession. We opened the Open Source Program Office at Sauce Labs anticipating that we can drive our product obsession on an organizational level even further. Moreover open source initiatives often provide additional strategic and operational advantages. When we support various OSS frameworks by improving their integration with Sauce Labs we increase the likelihood that users will run their tests with these frameworks on our platform, enjoying the best possible experience. This also helps us to connect with project communities, build up relationships and attract talent to join our company mission. Most importantly, by providing our developers with clear open source project policies and guidelines we can help them establish a better connection with their project, a key driver to increasing product obsession and their relationship to the customer.
Open source should be considered as part of every product roadmap and open source contributions included as essential deliverables of every product. This can only work if there are clear guidelines and policies that reflect the companies values of good open source software. The program office should not act as gatekeeper here and rather try to support every team it needs to. It is important that members of the office are involved in product and roadmap discussions to inform the team of important developments in the ecosystem as well as advise on product deliverables that supports building and growing our own ecosystem. For example, every public-facing API must be delivered with a programmable interface for users to download as a language package and used if desired. Every binary offered as a download to users must be delivered with a Docker image, a GitHub Action or similar integrations.
Photo by Annie Spratt (Unsplash)
These are the opportunities to build user communities that interact directly with the developers of your organization. These users will often end up filing issues directly in GitHub rather than raising a ticket with customer support, reducing both the drag on the support team and allowing the bug fixes to be detected and fixed more quickly. Suddenly features aren’t thrown over a wall anymore as engineers are exposed to direct user feedback. Additionally, shipping open source features provides a path to developer content that can be easily created with support of a marketing department, or as a conference or meetup presentation given by the developer. This type of exposure naturally boosts the connection between the developer, the product and the end user as well as between employee and employer given that the developer now represents the company and its mission in public.
Ultimately, encouraging the open sourcing of projects shifts the engineering culture from being isolated from end users to representatives of their own deliverables who understand the pain of their customers. Where a customer used to file a support ticket via email, that eventually transforms into a bug ticket and at some point is pulled into the sprint of an engineering team - such issues now are directly reported in a true open source fashion by filling an issue through GitHub. This drastically reduces the time between when a developer becomes aware of the issue and helps them prioritize as they have a direct technical understanding of it and its impact on user experience. With customer communication now being bidirectional, a continuous feedback loop is enabled that allows the creation of new ideas by the product team as well as by engineering. Such an open relationship with the customer overall builds a product obsessed culture that cultivates both innovation and great user experience.