Proposing a New Framework to Design for Growth

Jihern Baek
Thumbtack Design
Published in
6 min readJun 14, 2019

My friend, Paolo, wrote a comprehensive article about designing for growth if you’d like to learn more.

It’s not uncommon for designers to be tasked with creating product experiences that directly impact a company’s ability to monetize. In fact, many such designers do so on specialized growth teams, which enable businesses to focus and accelerate their efforts towards their metric-based goals.

I joined a growth team soon after I graduated college in 2016. And having newly entered the industry at the time, I was privileged to have had the opportunity to explore various disciplines of design and to quickly see the impact of my work through hyper-focused experiments. I continued to design for growth for almost two years before transitioning to another team, and I attribute so much of my development to that experience.

At the same time, designing for growth placed me into a system that often prioritized short-term monetization over long-term value. And in that experience, I saw designers burn out, UX debt compound, and in the worst cases, decisions that neglected users under the guise of company sustainability. In that regard, it seems self-fulfilling that going after monetary incentives by any means possible would lead to such adverse effects. That makes it all the more frustrating that we never reconsidered our philosophy, that striving to deliver real, consistent value was not at odds with our monetary incentives — it would actually be the reason we could build a sustainable business.

Ultimately, I believe there is a full and exhilarating conversation about how we design for growth that deserves our attention. To kick it off, here are four ideas I think could help us prioritize long-term value in the pursuit of building sustainable businesses.

1. Share the Responsibility

As mentioned above, most individuals who design for growth do so on a growth team. The reason is having designers focused on growth enables companies to accelerate their cadence of experimentation. And in that process, the goal often becomes about learning as quickly as possible to better understand what most effectively drives short-term monetization and other metric-based goals.

Expediting our learning through experimentation, however, feels deeply short-sighted. When we move as quickly as possible and with brute force, we often risk being reckless, having details fall through the cracks, and failing to see that meeting users’ needs actually drives business goals. As an example, designers are frequently tasked with running experiments on in-product paywalls. With metric-based objectives in hand, they’ll do what they can to convert users into paid ones. As a consequence of moving quickly, however, they may never have the opportunity to step back and ask what exactly users need in order to make informed decisions about why they should pay for a product. The resulting experience may lead to an inconsistent mixture of modals, banners, and emails — all making the same, tired calls for payment but leading to distrust, more customer support requests, and a churn rate that renders the short-term monetary gains useless in the long run.

In that regard, there are benefits to putting down stakes that force us to slow down and enable us to allocate more of our energy towards understanding our users. More specifically, sharing the responsibilities of growth across an entire design team, as opposed to a subset, ensures we commit to asking the right questions; prioritizing growth initiatives collectively and intentionally; and thinking about sustainable growth before throwing ourselves into experimentation. As an added benefit, I believe we’ll see a better distribution of types of work across design teams that will help reduce burnout — because, let’s be honest, designing paywalls over and over again can be demoralizing — and provide opportunities that help designers experience a wider variety of scopes of work.

2. Design Systematically

In the pursuit of driving short-term monetization, designing for growth often manifests as a series of initiatives to build or optimize a particular moment in a user’s journey. For example, I worked with my then team to both introduce and iterate on a series of paywalls that would surface whenever users attempted to utilize a paid feature. Our approach was to design these paywalls independently, so that we could optimize each individual instance and release them in an order we felt would be most impactful. Though this decision likely made sense at the time, what resulted was a set of upsells that added to the multitude of inconsistencies within our product and failed to establish recognizable, cohesive patterns that would have otherwise helped acclimate our users. To add to it all, we had to build these paywalls multiple times.

Ultimately, the decision for our approach was largely in pursuit of short-term monetization. Had we focused on delivering long-term value instead, we would have created a more robust system that would have helped users better navigate through our product, as well as scale our impact at a lesser cost. We would also have had more time to map out our user journey and better understand what competencies users needed to develop so as to maximize value and impact when they actually hit paywalls.

3. Use Metrics for Accountability, Not as the Goal

It’s known that quantitative data alone cannot give you a full picture of what your users experience. To give an example, my team had discovered a correlation between multi-device adoption and conversion. As such, we hypothesized that pushing more users to download the app on a second device during their first time experience would have downstream effects on conversion rates. Though we saw an increase in multi-client adoption, we didn’t see an increase in conversion. We had mistakenly assumed that directing users towards actions that reflected those of our paying users would benefit the business. Instead, we needed to understand that new users were likely trying to piece together the value of our product during their first time experience; that they wouldn’t yet have the comprehension levels needed to make decisions with intention; and that we were risking losing new users who would be expensive to re-engage.

Designing for growth is ultimately about driving monetization. But with the example above and countless others, why do we continue enabling ourselves to set metrics as goals if data alone cannot convey the full implications of our product decisions? There is greater value in viewing the role of metrics as a means of holding ourselves accountable, as opposed to the goal itself. In doing so, we center problems and objectives around the user, solving for long-term value as opposed to an incomplete metric.

4. Share Learnings Cross-Functionally

Though I believe we could have been more strategic about what learnings we sought after, my team had accrued plenty of insights that were valuable and could be applied by other product teams. For example, we understood how to frame copy across a multitude of scenarios, as well as what behavioral principles were most effective at a given time. But because we were so deeply focused on driving metrics quickly, we never got around to institutionalizing a process that pushed us to package our learnings and enabled other teams to prioritize those learnings into actual sprints.

At the end of the day, experimentation is not without cost. As such, there is value in optimizing our learnings by establishing workflows that catalyze them into cross-functional applications. In doing so, I believe we push ourselves to think more thoughtfully and systematically about what we need to learn and how we apply our learnings in our product.

Altogether, I believe these ideas catalyze a different approach to design for growth, one that encourages us to solve problems holistically and that reifies the idea that the pursuit of long-term value enables us to build stronger businesses. To that extent, I’m always trying to learn more. If you have thoughts or questions, I’d love to hear them.

Special thanks to my peer reviewers and good friends:
Cordelia Hyland, Cory Weaver, Jimmy Dunn, Roslyn Coutinho, Paolo Ertreo, and Jordan Berry