Highlights
Can you tell us about your role at Webflow and what your company does?
Frank Ramirez: Webflow is a company that builds, what we like to think of as, a visual software development environment for no-code creators. You could think of it as a website builder, but our ambitions are much broader than just websites in the future.
We’re on a mission to enable anyone to create software on the web. I’ve been a PM at Webflow for the last two years. Recently, I’ve stepped into a group leadership role.
Now, I’m building out a team of exceptional PMs focused on, what we call, our ecosystem. We’re really thinking about how we can really create an economy of creators on top of Webflow. We want creators selling things like templates, design assets, design systems, and more to other no-code builders. Additionally, we’re thinking about how third party developers can really extend the core experience of Webflow and fill in all those use case gaps that we're never going to be able to get to ourselves to create an amazing experience for our customers.
Tell us a bit about your team and the PMs you’re working with.
Frank: Currently I’m working with three PMs. I'm looking to hire a few more as well. These PMs are all focused on different areas of the product– whether it's the core product or thinking of our content management system, which is what a lot of people think of as the core piece of what's slow in Webflow.
Some of my team is working on upcoming feature launches. We have PMs thinking about our ecosystem and thinking about how Webflow can be extended via APIs, SDK, and more.
Can you talk about the product sense skills that you look to nurture across your team
Frank: Product sense is a really important component of decision-making. At it’s best, product sense is a deeply informed, educated guess.
At it’s worst, it's just an unchecked assumption. So, as a leader, how can I look for that in PMs? To me, it’s all about uncovering the assumptions at any stage of product development. Especially in the beginning where taking a wrong assumption early on that is not built into a process of validation or checking in can have a larger and compounding impact later on down the line.
Early in their careers, product managers need to be encouraged to think in processes. They need to be explicit and look for ways to de-risk their testing. Tactically, those things can look like templates.
For instance, at Webflow, as we continue to grow our headcount across product, we’re thinking about elevating and really standardizing our processes. We need to ensure that every PM can follow best practices.
How do you know which bets you can make as a team?
Frank: A lot of it's going to come down to how strong your perspective is on the market, the customer, and the product that you're building.
I think that the stronger your perspective is on each of those, you’re in better shape for a risky bet. Especially if it's been validated through a bit of time. So, this is hard for a brand new PMs to do if they’re fresh to a market or a certain customer segment, or even working with a new product.
But if you've been working for a while in a certain area, I think you can leverage your expertise a bit more. And I think that speaks to the idea of pattern recognition. I can give you an example where I've leveraged it a lot and really leaned in on my product sense.
In visual design, any time you’re working with a canvas, you don’t want to bound your customer too much. You want your customer to be able to build whatever they like. So, naturally, there's a huge long tail of bets, use cases, and edge cases that customers will try to do or try to build that you won't be able to necessarily plan for. They’ll look like isolated cases.
If you have a deep conviction of the type of experience you want to deliver to your customers, then you can look at the commonalities across these disparate use cases and come up with abstractions that cover many of them.
You don't want to solve just one customer's problem. You want to generalize it.
Validating your tech stack is trickier than validating a simple design. How do you go about this?
Frank: We had a scenario where many of the engineering leaders were coming from a gaming background. So, they ended up choosing a gaming engine as a rendering environment for the UI.
No question that gaming engines can create great graphics. But what we didn't really think through was the product development process we were going to go through. So, we had to come back to that.
I think we can really illustrate two key points. Number one, what are the customer outcomes we're really striving to enable with whatever tech stack that we use? It should be a means to an end. People don't buy the tech stack, they're buying the product and the experiences we create for them.
Creating those hero flows to illustrate the grand vision really challenges our team to compare tech stacks that can help us serve this user well.
Bringing in that customer context is number one. Number two– how quickly of a release and iteration cycle do we really want? What expertise do we have on the team and how do we bring in other cross-functional members like product design or QA into this kind of development process?
Thinking of that as a little bit of a life cycle would have helped out a lot. We would have found that there's a high barrier to entrance for designers when it comes to gaming engines as opposed to a web engine.
Can you tell us about how you deal with inheriting old roadmaps?
Frank: I inherited a roadmap and went along with it without really questioning it. In retrospect, that was good and bed. Doing this definitely taught us a lot about our own development processes. We learned about the limits of our product that will inform future roadmap items.
But generally speaking, this is a common situation for any PM to come into. When you come into a new organization and there’s a lot of existing thinking done, you ask yourself, “do I just use it?” I think in some cases it's okay to quickly leverage someone else who was from that era.
If you can, however, I encourage first principles thinking. Spend time thinking about the key motivators and drivers.
What are the key outcomes for the product that you're owning? And then come up with a plan based off of that. But that can take weeks, if not months, especially if you're onboarding to a brand new space.
That's where a little bit of intuition comes in. That's where you're talking to other members of the team. That's where maybe you're leveraging more of your engineering lead or design lead, who may have more shared context getting up to this point.
You’ve described PMs as the centre of a spider web holding everything together. Can you talk more about why you use this analogy?
Frank: This is how I quickly visualize the role of a product manager. There's a lot of times when people talk about the role of a product manager, they tend to say there's user experience, then business management, and then there's engineering.
In the middle of that Venn diagram, that's where you are. That’s the PM. But going beyond the simple description, PMs need to have a bit of an ear to the ground with customer support and sales. They need to have a self-serve relationship with data.
Being a PM is really about having a central context point. Why and what is the organization doing?
I heard that you believe PMs need to find their “superpower.” What superpower do you think you might have?
Frank: I started my career in engineering. Did that for quite a few years and then decided that engineering was not for me. I realized that product management was what I wanted to do. So, I had to find a product management role. That’s a very difficult transition for anyone to make.
In those cases, what I recommend to people is to find their superpower. What is it about your background that you can really leverage and position yourself for? Whether it's company type, technology type, or stage of company. Where is that your unique background can be amplified by a PM role?
I think my superpower is communication, especially asynchronous communication. As well as a technical bias having been an engineer. I know that generally speaking, on every development team PMs are going to be generally technical, relative to the regular population. But you also have some PM's that are definitely technical because they were engineers themselves.
About Our Guest – Frank Ramirez
Big thank you to our guest, Frank Ramirez, for joining us on this episode of Product to Product! To learn more about his product thinking, follow Frank on LinkedIn.