Rethinking Webflow's Research Team Structure

Companies decide to reorganize and restructure their teams and departments all the time, but how often do you get to see their reasoning? When I joined Webflow in July of 2024, there was a pretty clear charter: shift our research practice from reactive (and tactical) to proactive (and more strategic).

Let’s talk through where the Research team was before I joined, what forces we’re adapting to, and the direction we’re heading.

Reactive vs. proactive research teams

I owe tremendous gratitude to the previous Webflow leaders for hiring an excellent team that I was lucky enough to inherit. They developed a structure that solved what Webflow needed at the time: a team deeply embedded within Webflow’s Product pillars. However, this, along with various other reasons, led the Insights org (which includes Data Analytics, Data Science, Machine Learning, and Research) to fall into a pattern of reactivity: we weren’t controlling or driving our own roadmap and instead letting our stakeholders dictate what we do and, therefore, what value we provide. 

This was further exacerbated by new requests the Insights org was getting from leadership. In addition to providing answers to questions our business partners need to make decisions, we were being asked to influence more of our corporate strategy. It’s a blessing and a curse: it’s great to be involved in those conversations, but it put us in a bind because we didn’t have the bandwidth or operating model to support those requests. In fact, these are two fundamentally different ways of working: one helps deliver the existing roadmap, whereas the other helps identify what the roadmap should be.

We wanted to reverse the reactive trend and get out ahead of the roadmap, but you can’t just flip a switch. So, what do you do?

Shifting to a more strategic research practice

Reactive or not, one thing was clear: our Product and Design partners needed research support. The decision to embed was obviously paying dividends: researchers were seen as highly valuable and trusted assets, so we couldn’t just pull the plug on them and withdraw our researchers without having something in place to fill that need. Enter what I’ve recently started calling “the D-word."

The D-word

Democratization has gotten kind of a bad rap lately (see Great Question’s 2025 State of Democratization Report for more on that). But when done right, it’s an invaluable tool. The potentially negative associations that have developed over the past five years lead me to use different language to refer to the same concept. At Auth0, we called it “Lightweight Research,” and at Webflow, we’re calling it “DIY Research.”

With a team of four Researchers, one ReOps, and 22 Product teams, we had two options: 2-5x the size of our team or find another way 😅. In that sense, there really was no other option other than to focus on Research Enablement. Even if we wanted to hire that many researchers (more on that soon), we simply couldn’t grow fast enough to meet the demand we already had, so we launched the DIY Research Program in Q4. We’ve already seen 12 projects completed by our PM and Design partners and are in the process of rolling that out to Marketing, Customer Success, and Sales.

Building a roadmap

Another thing we were able to start heading into Q4 that really took hold at the start of FY26:* building a roadmap for Research. Having a DIY process in place gave us the ability to triage incoming requests and decide what can be DIYed versus what is a good use of our time. We developed a set of principles to help stakeholders understand our decisions: risk, complexity, scope, and urgency.

By the time EOQ4 rolled around, I’d been at the company long enough to form an opinion on what Research should be working on. I like to call these “existential questions”, as they often relate to:

• Core parts of our business
• Foundational understanding of our users/customers/target market
• Major shifts in the industry that we want to get ahead of. 

Heading into Q4, though, I did something simple that turned out to be highly elucidating: I asked my embedded researchers to put all of the requests they were getting into a spreadsheet. Four researchers across five product pillars produced 46 requests for Q4. If you’re doing the math at home, that’s 11.5 requests per researcher, or approximately one study per person per week 😳. This highlighted the tremendous demand for research, the impossibility of us to serve all of those needs with our current team, and the potential for DIY to have a huge impact.

*Note: Webflow's fiscal year is February - January.

Where are we now & a look ahead

Over the course of Q4 and Q1, a few changes have started to take place. We’ve already talked about DIY, but we’ve also had some personnel changes. For one, all of this talk about ratios (we’re targeting 2.5:1 PM/PD:UR, 10:1 UR:ReOps, and 50:1 PWDR:ReOps) and the above discussion about request load allowed us to open four roles: one Research Program Manager to lead our Ops function, and three Researchers to help increase coverage. We also had our Staff Researcher depart, which created a bit of an existential question of our own: what do we do with that backfill?

One thing had become clear heading into FY26: DIY was working, which created some additional time for our Researchers, but there was still some tension between working on pillar projects vs. working on our roadmap. There simply wasn’t enough time for one person to do both, and not all requests could be DIYed. Anticipating this, my original proposal was to pull our Staff Researcher away from pillar work and dedicate them to “Strategic Insights.”

Alongside that, however, another need emerged: someone to set strategy for our pillar work. In smaller teams/companies, the Head of Research role is actually several jobs rolled into one, e.g.

1. Managing a team of Researchers
2. Setting the overall Research strategy
3. Building & directing Research Operations
4. Triaging requests and building research plans

With the departure of our Staff Researcher, I started talking to my peers and to leadership to decide which of the two vacancies we should fill first: the Strategic Research lead to focus on the 6-36 month time horizon, or the Product Pillar lead to make sure we’re driving the most value for our Product and Design partners. Out of these discussions, a third (and now somewhat obvious 🙈) option emerged: hire a manager.

Specifically, hire a manager, give them some of the less-tenured folks, dedicate that team to the product pillar support, then work with your more-senior ICs to figure out what this "Strategic Research" thing looks like. This solves a variety of problems:

1. Growing the team is great; having 9 direct reports is not 😅
2. Two teams/managers == clear division of labor between Pillars & “Portfolio”
3. More coaching and hands-on time for our ICs
4. Dedicated team members to charter the Strategic Insights function

This takes us to April 2025, when I am writing this piece. I am confident that this is the right move given where we are and what we want to accomplish next, but as is often the case when making any decision as a leader, you never know for sure how it will turn out. Take your best guess given what you know now, identify a few key signals to pay attention to (e.g. how many requests we’re getting for support and what types of requests), and be willing to adapt. Adapting is how we got to our current structure so why stop now?