Lessons learned as Snap CI Product Manager
Posted by Suzie Prince
Prompted and inspired by the thoughtful and retrospective questions asked on the Roadmunk blog I wanted to take a look at my first year as the product manager for the Snap CI team and share with you my top 5 lessons learned from 2016.
CI/CD remains unclear to many
Highlighted by the study that Emily and I conducted during 2016 where we saw that there was no consensus on the definitions of continuous integration (CI), continuous delivery (CD), or continuous deployment, it became clear to me this year that the level of understanding about how and what these practices are was much lower than I had previously thought. This insight was also compounded by the value that people found in our blog posts and conference talk about CI and CD, as well as the continuing success of conferences like DevOpsDays for those new to the practices.
Takeaway:
My hope for 2017 is that the understanding of, not only what these processes and practices are, but also how they can be valuable to all roles and organizations large and small increases. Let’s make 2017 the year we all understand and practice continuous delivery.
Developers are regular people too
I have created products for software development teams for the last 8 years, but this was the first year the primary user of the software was a developer or software engineer. Although I am a great believer in checking your assumptions and biases — it doesn’t mean that I don’t have them! And this year revealed that I had quite a lot about developers; I had made a bunch of assumptions about how and what they knew about other roles and practices in the product development process.
As an example; when asking developers to help me with customer development, a usability study or a contextual inquiry, I had assumed they understood these terms. As creators of software I assumed that they would not only have been aware of these practices but would also understand why, as a product manager for a developer tool, I would want to ask them questions about how they work or watch them use their dev tools. This was not the case and I was surprised to be met with responses such as “I just do normal coding stuff” or “why don’t you send me the tasks and I’ll write my feedback up for you?”
Takeaway:
These responses taught me that I still needed to articulate the value and benefit of what I was doing. It also highlighted that I could not rely on developers, as software creators themselves, to articulate feedback to me in a way that was valuable, rather than feature driven. I still needed to do the deep diving to get a good understanding and do analysis to get to the heart of what our users were saying and sharing.
Not only is that personally relevant to me and the products we build, but it is also a reminder to us all to get to know the people we are building our products for. In-depth conversations and observations can reveal nuances that we cannot assume we know. Although I see many teams dogfooding their own software to “test it” I do not believe this is enough because it is based on an assumption that you are your user — and you are not. I highly recommend that all creators of software for developers use techniques such as usability tests and contextual inquiry research to learn more.
Serverless is changing how we build products
One of the biggest trends that stood out to me last year in terms of new technology was “serverless.” We saw more and more of our customers using internet based systems where their application did not use the usual server process but rather relied on a third-party service, client-side logic, and/or service hosted remote procedure calls. The ability for these technologies to reduce cost, save time and allow smaller organizations to handle load and act like larger organizations is why many are turning to serverless to help them build their business. For software developers like those who use products like Snap, that embrace the cloud and work on lean, fast moving teams, I think the serverless trend is empowering and industry changing.
Takeaway:
In 2017 I hope to see more growth in serverless vendors and more thought into the testing and deployment of these serverless architectures to better enable teams to move quickly and effectively while still producing quality software.
A truly agile team is a team practicing DevOps
Although I have worked with and ran agile teams who have SaaS based products before, this was the first year that I worked with a completely cross functional team who truly were all the things a DevOps team should be. The Snap team runs everything from idea to deployment and operation. Every team member has been at the forefront of a new feature, seen it evolve in development, deployed it and watched it grow in use once in production. Everyone is an analyst, a developer and an ops person. We do ideation and we do support. We all know and love PagerDuty. The powerful learnings we gain from being such a cross-functional team are that: we are very empathic to each role, we all have a high level of understanding about why features are built, how the product is used in production and what could be improved at any given time. The shared understanding that we have created with this way of working means that, more than at any other time in my career, I know that the decisions we are all making everyday are correct and aligned. I truly trust that when one of us calls to resolve something they do so understanding the impact on the full team, process and end user.
Takeaway:
Creation of cross functional teams takes time and patience. It can feel overwhelming that everyone is aware of and responsible for so much. However, the benefits outweigh the effort. I will continue to focus on working with and growing truly cross functional DevOps teams as I believe they are the best product teams there can be.
Build it and they will come is a myth technologists need to get over
The saying “build it and they will come” is something many people in the tech industry say and believe. It has long been something I do not believe. However last year, after working closely with many small businesses with great technology ideas that did not succeed, it became solidified in me the naivety of our industry. Many software developers believe that if you have this great idea that the hard work is done. The failure of so many startups and small businesses mean that it should be clear to us all by 2017 that you can’t just make this magical thing and hope that people will come use it.
Takeaway:
You need to invest in understanding your user, building the right product and telling the right people. Without a holistic and complete plan for your business, your great idea might never get off the ground. And 2017 doesn’t need any of those disappointments.
