A common issue leaders in product management, design, or engineering face is justifying investment in the “non-sexy” stuff. What is not sexy can differ by company, but usually the sexy things are new products and few features. Non-sexy things include general user experience improvements, performance, developer velocity, infrastructure, technical debt, and, fortunately less than it used to be, growth. I’ll walk through some frameworks and examples from my career on how to drive excitement and investment in these critical areas that may not be properly valued or staffed currently in your organization. But I urge everyone I can in product to develop the intuition to support these initiatives without making teams jump through hoops to justify these investments.
User Experience
The most common path product teams are on today is that they go from feature to feature trying to add new functionality, never confirming their feature actually adds value, and never improving features over time or updating experiences to be more modern as the world evolves. Designers complain about how stale certain experiences get over time, but improvements never make the roadmap. Product managers think designers are whining about things that aren’t important versus their current OKRs.
Why are the designers right in this instance? Well, they aren’t always. It is possible to over-design and do things that feel good and look excellent, but don’t materially help your customers or the business. Polishing too often can be just as bad polishing too little as you don’t deliver enough new value for customers. While over-polish does happen, why designers are mostly right is they intuit something about product/market fit that is hard to measure on a metrics dashboard: that expectations of customers increase over time. Another way to say that is product/market fit has a positive slope. If you do not consistently improve your product or feature, and customer expectations continue to increase, your product or feature can fall out of product/market fit over time. Many business strategists talk about companies being in a Red Queen effect with their competitors. This means they have to run really hard to stay in the same place competitively over time. But what many product teams misunderstand is that they are in a Red Queen effect with their customers to maintain product/market fit as well. Consistently improving the user experience helps products stay above that positive sloping curve of product/market fit. Let’s visualize this by borrowing a graphic from my product/market fit essay.
In the above graphic, the customer expectations line is the point at which customers stop complaining about elements of a product. That is not the target for product/market fit. The target for product/market fit is the purple line where customers stop leaving a product. Teams invest in products and features to get them above the purple line, but failing to continue to invest in them beyond that point means expectations for product/market fit will eventually exceed what has been built without continued investment.
The dotted line is a worst case scenario as it happens in a way that is not measurable, but once those hard to define lines cross, every metric gets worse. So, in prioritizing user experience improvements that scale with customer expectations, the net effect you see is no impact in business metrics. But the effect of not doing these investments means business metrics will decrease over time. This practically means that teams that make investments feel like the investment didn’t “pay off”, but in reality it prevents the possibility of dramatic issues for the product down the line.
On the growth team at Pinterest, Kaisha Hom and Lindsay Norman on the growth design team intuited this, but had trouble convincing a very metric-oriented team on the value of this investment. Eventually, we decided that one of our key results would be a quarterly audit (and refresh if needed) of our top five user flows. The expectation was no material impact on growth, but instead prevented potential growth issues down the road.
At Eventbrite, we have gotten a little more sophisticated in how we manage this. Adele Maynes, who leads our research team, helped craft a survey that measured different components of our product/market fit, including:
- Ease of discovery
- Ease of use
- Ability to self-serve
- Product fit
- Likelihood to recommend
We also created this survey for some of our key features inside the product so we can understand their feature/product fit better. Our new strategy is to be a fantastic self-service experience that rivals the best SMB tools on the market, but we know we have a long way to go to get there. Investing in user experience is a key driver of this strategy, and these scores help us know if our overall product and specific features are on the right track. CRPX is now one of the top level key results for the product team.
Sample analysis of Eventbrite’s Creator Product Experience Score (CRPX)
Performance
Performance, roughly meaning how long it takes for software products to become usable to customers who load them, tends to become a problem at scale without concrete investment. Products become bloated, the number of different types of users and use cases multiply across countries and categories, and the number of frameworks engineers are leveraging to deliver experiences rises exponentially. We actually have pretty good data externally on the impact of performance. There are many studies that show additional milliseconds of load time impact things like conversion to purchase and engagement on many websites and apps.
A big problem is actually addressing performance issues at the start tends to be measuring it well, across different pages, apps, countries, use cases, etc. Obviously, this is normally the place to start. But sometimes even shockingly high metrics in certain countries or at the edges can’t motivate teams to scrap their current OKRs for performance work.
On the growth team at Pinterest, we were struggling with some performance issues of our home grown frontend framework. After trying to rally the company around this work and failing, we decided to leverage our skills to prove out the value of this work. A small team of engineers led by Sam Meder decided to work part-time on a performance initiative just for our logged out experiences, migrating to React, server side rendering, lazy loading, spriting – all the usual suspects from a frontend performance perspective. They ran these changes as AB tests to show the impact on user engagement and key business metrics. The result was a 30% decrease in user-perceived wait time, which resulted in double digit= increases in traffic from Google and conversion rate to signup. The impact was enough to get our CEO to push this as an organization-wide initiative the following quarter.
Developer Velocity
Shortly after I joined Eventbrite, I ran into Omar Seyal on the street. Omar was the Head of Core Product at Pinterest at the time. As I said hello and asked him how things were going, Omar, always to the point, remarked, “Pinterest doesn’t understand leverage!”. He then went on to say how he was struggling to get Pinterest to invest in its infrastructure so that engineers could move faster. In my head, I thought, he doesn’t know how good he has it compared to Eventbrite. Startups, or companies that emerge from startups, tend to prioritize new customer value and growth at all costs. This not only can create a lot of technical and design debt that will slow companies down for years to come, but it also prevents them from seeing “what got you here won’t get you there.” At a certain point in a startup’s lifecycle, it has to shift from growth at all costs to balancing growth and long-term scalability. Yes, you could spend 90% of your time building new things when you were small, but that won’t work when you’re big and have dozens of things to maintain.
A belief Omar and I share is that developer velocity is the purest form of leverage in a software company. So, it follows, investments in things that make developers more productive are the highest leverage investments a company can make. Sure, those investments don’t translate into customer value directly, but they enable each developer to build more customer value. That can mean more features, more experiments for a growth team, whatever the company needs to maximize long term growth. The key question I think non-developers fear is that these are just quality of life investments and don’t actually meaningfully improve the amount of value to customers. After all, you’re spending less resources on value to customers in the short-term whenever you look inward at internal tools.
What we did at Eventbrite to confront this narrative is we built a measurement plan and a goal. First, we measured the amount of downtime our developers experience on a quarterly basis for various issues. We then stated that with investment we could decrease that downtime, freeing up more capacity to build value for customers. We then set a goal. By making these investments, James Reichardt and Dan Peterson, our leaders in platform engineering and product, argued we could free up the equivalent of 15 new engineers’ worth of capacity at the company. In the end, those investments freed up 18 engineers’ worth of capacity. We confirmed this with “end of sprint” reporting on different teams on the amount of what they were able to deliver. If those numbers aren’t improving over time, you’re probably under-investing in projects related to developer velocity.
Engineering downtime was actually trending upward, but by working on our tooling we were able to save hours per engineer per week.
Growth
As much as I’ve written about the rise of growth teams and how growth teams work, the concept of investing in things that help connect customers to value instead of building new value is still pretty nascent in the software world. I speak to product managers and leaders all the time that are struggling to get investment in areas that could help inflect their growth. We definitely faced some of these same issues when I started at Pinterest. While we had a dedicated growth team, many parts of our growth model felt under-optimized, but also hard to measure or justify investment for.
One of these areas was search engine optimization. A few months before I got to Pinterest, Pinterest had “no indexed” the entire site, leading Google to email us to confirm that was what we wanted (it wasn’t). Anna Majkowska jumped onto the problem, but was only able to secure a few part-time engineers to help her. I joined shortly after as the PM, and we worked together on a plan to improve SEO for Pinterest as we believed that to be a large growth opportunity. The problem was we were on a growth team that ran every change as an AB test to show the improvement in growth. With SEO, you can’t run AB tests because it’s one Googlebot instead of millions of separate users. Julie Trier, a part-time engineer on the team at the time, said we had to develop an SEO experiment framework like we use for other parts of the growth team, and set out to build it. With this initial version, instead of showing different users different experiences, we changed parts of the experiences on some pages and not on others and measured the traffic change from SEO. The framework worked, and helped us justify SEO investments by showing how much extra traffic we received from making changes.
More traffic was great, but the issue was that users from Google would just look at all our cool content and leave. Conversion rates were very low. Conversion was managed by another team. So I went to them and explained the opportunity. They said they were busy working on a home page overhaul and couldn’t look at it. So I said we’ll take on the work ourselves. By then Jean Yang had joined the SEO team and ran an experiment that increased traffic, but decreased sign ups. How that was possible was by making a new page available to Google, we removed a signup modal blocking logged out users from accessing it. It turns out people signed up when they saw that modal, so we hypothesized maybe we could trigger that modal when you clicked on an image when you didn’t have an account. Also, we thought the other thing that indicates you like what you’re seeing and should sign up besides a click on an image is scrolling down and viewing more images. We already restricted Google from seeing more than 25 images on a page, so we decided to make the same change with users, with a modal coming up from the bottom saying to sign up to see more.
It took Jean two days to implement the experiment, and the result was a 50% increase in conversion rate to sign up. Every graph at the company kinked up as a result. I got a message from Tim Kendall, our Head of Product, asking “What did you do??”. I thought he might fire me, but instead he used the data to go raise more money at a higher valuation showing investors we could inflect our growth. Don’t under-estimate the power of proving it by going rogue or making the measurement investment others think isn’t worth it. It can turn subjective conversations into objective ones very quickly. The team grew dramatically after this with Julie eventually leading a platform team for growth tools.
–
These are just a few examples of how teams were able to make the investment case and prove the value of “non-sexy” projects to make a big impact. Of course, what tactics work for you will depend a lot on your company’s culture, but one thing that will likely mimic these stories is teams working together to make both the case and execute on the investment. Building products is a team sport, and the more cross-functional the support you achieve, the more likely you are to succeed.
As I relay these types of stories, it’s easy for people to say something to the effect of “sure, that worked at Pinterest or Eventbrite, but it could never work here” without realizing the point of the story is that almost all companies have these types of issues. The question is whether you are willing to put in the work to try to change the narrative to help your company grow. Those that do typically are rewarded and reward their customers in the process.
Currently listening to my Trip-hop playlist on Spotify.