Product Lessons Learned: Interview With Ronnie Regev, Sr. Product Manager (Part 1)
LIKE.TG 成立于2020年，总部位于马来西亚，是首家汇集全球互联网产品，提供一站式软件产品解决方案的综合性品牌。唯一官方网站：www.like.tg
This is the first in a series of interviews that we’ll be conducting with product managers across various industries. We’re curious to hear about how they got into product management and about their experiences on the job. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike.
Our first conversation is with Ronnie Regev, an experienced product manager at AppFolio (a California-based SaaS company that builds software for property managers). Here’s Ronnie’s story.
How did you get into product management?
Ronnie Regev (RR): Like many product managers, my route to the role was long and indirect. There aren’t a whole lot of people who finish school and end up in product management right away. Most people come into it from something else — and in my case, I spent about eight years working in infrastructure and operations in the video game industry.
It was a very interesting job and it was very technical. But I grew increasingly frustrated with being on the receiving end of business decisions that were made really far away from my team. Inevitably, my team would have to solve problems that we weren’t involved in identifying or qualifying. Also, because we were in a back-end type of role, it was difficult to see how the work we were doing was directly contributing to the success of the company.
Over the course of several years, I started to take on a bit of that frustrated mindset. It never affected my work, and I was still really happy in my job, but at a certain point, I decided to leave the company. I had been working there for a long time and I wanted to do something a little bit different.
As I started interviewing for other IT infrastructure operations leadership roles, I realized that I actually wanted to try something else. Through a friend, I was introduced to the director of product management at RightScale, who told me that I might find product management interesting.
I had a pretty open mind. I was starting to figure out what I didn’t want to do, but I still needed to figure out what I wanted to do. I thought, “Well, product management, I don’t really know very much about this. It’s just a conversation. Let’s see how it goes.”
What seemed really appealing to me about RightScale was that I’d be able to use my subject matter knowledge — my understanding of systems engineering and infrastructure and scalable web systems in a new, more challenging and satisfying way. I’d be speaking to people who used systems like the ones I was used to using, understanding their challenges and then working with engineers and designers to actually build software that solved their problems.
I didn’t even realize that was a job — something that somebody would be willing to pay me to do. When I put everything together, I thought, “Wow this seems like such an appealing idea.”
I’d get to use my historical knowledge and my interest in speaking to people about what’s difficult for them to inform how software gets developed. And I’d get to to be hands on with a technical team. Product management is not purely a marketing-facing type of role — there’s still this technical aspect of it which was appealing to me with my career background.
That was my path into product management. I happened to meet the right person at the right time, and it clicked for me. I met the director of product management at RightScale, who was able to identify that I had whatever intangible qualities a product manager should have and gave me a chance in the role. After two years at RightScale I moved on to AppFolio for a new opportunity and, over four years later, I’m still happy a Product Manager.
What do you love about your job and what’s challenging?
RR: What I love about the job and what’s challenging about it are sometimes the same thing.
I love that point in time when we’re about to release a new feature or a new product to our customers. There’s this nervous excitement that my team has. It’s a really special time because it’s the result of a lot of hard work, and maybe also some frustration and arguments.
Another reason for excitement around a feature release is the anticipation of user feedback and usage data. We may be confident in the choices made but qualitative and quantitative feedback is the proof! Once we get that proof it reinforces the positive impact on our customers’ business and AppFolio’s as well; exactly the kind of career choice validation I sought!
A lot goes into that moment when we’re about to release something — a lot of individual opinions and insights from our customers. And it doesn’t necessarily have to be a big new feature or a big new product. We could be releasing something really small — in which case, the excitement is based on challenging our own assumptions and assertions.
Tweet This:
“Always question your assumptions.” #ProductLessons
Another thing I love is collaborating with the teams that I’ve been fortunate enough to work with — QA engineers, designers, and software developers who are really interested in solving problems and invested in understanding the context we’re working in. Being part of these teams has been a fantastic privilege and it makes work so much fun.
As for the things that are hard, I’d say combating my own biases is challenging. Like anyone else, I have my assumptions about what’s most valuable for our business, what’s most valuable for our customers, what the best path is in solving a particular problem. The hardest thing is to extract myself from those assumptions and overtly challenge them. But that also kind of falls in line with the things that I love about my job, because I consistently learn about myself, product development, our customers, etc…
Another thing that’s really difficult is always maintaining a focus on customer value. It’s easy to start thinking that we should do something because we’ll make more money — or because maybe we think we can grow adoption or satisfy an internal stakeholder. But at the end of the day, we should be focusing on delivering value to customers, and all those other things will follow.
How do you manage conflicting priorities within the organization?
RR: All of the conversations that I have with different stakeholders — with executives, sales, marketing, customer success, and engineering — are focused on a particular problem that we want to solve or an opportunity that we’ve identified to deliver value to our customers.
We frame discussions in the context of how does this align with our goals as a business? And the product management group has the benefit of very strong insight into our company goals.
Tweet This:
“Frame discussions in the context of business goals.” #ProductLessons
To use generic terms, goals for a company could be to increase the adoption of certain features, to increase revenue, or to become more profitable, etc. Whatever those goals are, they’re very clearly communicated to the product team and expressed throughout the organization.
Let’s use a hypothetical goal — to increase adoption of a particular product line, for example. That message will have been communicated to department leaders by the VP of Product and by the Directors of Product.
We get direction from the top down — from our board of directors, to the C suite of the company, to the VP level, and then down to the product line owners. There’s a lot of vertical alignment on what we’re trying to accomplish as a business. So when we’re framing a conversation around trying to increase the adoption of “x” product line, there’s very little debate around why are we trying to increase the adoption of “x” product line in the first place.
Company alignment is being worked on all the time — both vertically, up and down the corporate ladder, and horizontally, across all parts of the organization; product development, engineering, customer success, sales, marketing and operations. So for us, managing conflicting priorities is well solved by ensuring that there’s consistent alignment on goals.
What are some of the tools you use regularly as a product manager?
RR: I have a couple different classifications of tools. I have tools that I use personally for my job, and tools that I use in a group setting.
Evernote is a great example of a tool that I can’t live without. I have years and years and years of notes in Evernote. I’m also a very heavy user of Google Apps — Google Drive, Gmail, and Google Calendar. I use Google Docs, Google Sheets, and Google Presentations. Specifically, I find the collaboration aspect of Google Docs indispensable.
Also, I almost always have a pen and some Post-it notes in my pocket. My wife makes fun of me because I will usually slip a little pad of Post-its and a pen into my shirt pocket before I leave in the morning. She’ll call me a dork or a nerd and ask me if she should buy me a pocket protector. I’ve actually had ink open up in my shirt pocket before.
For team-oriented work, I’m not very dogmatic about tools. My view is what’s the best tool for the job? And we have myriad tools that are employed here at AppFolio. For example, we have some teams that do all of their planning work on a whiteboard. Someone will draw up a scrum board on a whiteboard so we can track stories to groom, work in progress, and so on.
We also have teams that work with Trello and other teams that work with Pivotal Tracker for managing backlogs and tracking work in-progress. One other tool that I find particularly valuable is called Kanban Tool — we use it a lot for user story mapping sessions. It’s a good way to capture and memorialize information.
Beyond that, it’s important to have consistency in tools that are used to communicate across the organization. For example, we use Google Sites to capture release literature and send it around internally — and it’s always the same form and the same destination. People in the company know where to go to find release notes.
Additionally, all of our product managers use LIKE.TG to track their two-to-eight-week roadmaps, and those roadmaps are always in the same format. Anybody in the company who receives a roadmap knows what it’s going to look like — they know it’s not going to behave any differently.
My personal go-to tools are Google Apps, Evernote and Post-its. When it comes to the tools that my teams use, I’m happy with whatever tool is appropriate for the job. And if it’s a tool that’s being used to communicate broadly, then I think consistency is more important than the type of tool chosen.
How do you plan your product roadmap at AppFolio?
RR: At AppFolio, product managers maintain roughly a two month outlook on what their teams are doing. I frankly don’t know the origin of that time horizon — maybe we originally had a two month release cadence at some point.
Anyways, each product manager owns the visibility into the next two months of work for their respective teams. Now, two months out, things are still kind of vague. The closer we get, the greater our confidence in estimates and in the fidelity of the problems that are going to be solved.
For historical reasons, our sprints are in two-week cycles — even though we now release code on a weekly basis. But since everybody in our company is used to “sprint” meaning two weeks, we’ve kept that definition. Product managers therefore work with blocks of two weeks at time on their roadmaps.
Typically, the product managers will meet with their teams once or twice a week for very informal sprint planning. Then they’ll update the two-week horizon, the four-week horizon, the six-week time horizon, and the eight-week time horizon. Predictability and certainty of roadmap items decreases further out on the roadmap.
Our roadmaps are communicated to the whole organization every two weeks, in a traditional roadmap form — with swimlanes, blocks, various colors, and so on.
Now, for the longer-term view, we don’t really have roadmaps. We have six themes that are derived from our business objectives. These are things like expanding our market, increasing feature adoption, enhancing our user experience, retaining our promoters, etc. We revise our themes every six months because things change, or because we’ve made a lot of progress toward one theme and there’s no point in continuing — we shift to another one.
Product Managers and User Experience Designers are paired to curate a theme backlog. They’re responsible for working cross-functionally to understand the various needs across the organization. They talk to customers on a regular basis, quantitative analysis, perform market research to identify and qualify opportunities. Then, using that data, they curate a backlog of problem statements that are then prioritized for teams to pick up.
Tweet This:
“Curate the backlog based on user input and quantitative analysis.” #ProductLessons
Teams have three top priorities across all the various themes, and product managers influence the teams towards certain themes. So, if we feel like we need to put a lot of emphasis on increasing adoption of a particular feature, then that message will be conveyed.
Download the free Backlog Refinement: How to Prioritize What Matters Book➜
The product manager will say, “Hey, pick one of these three opportunities. Don’t pick something from the expand our market theme. We’ve done that. We have a lot of work in flight over there, or we’ve put a lot of groundwork in place already for expanding into adjacent markets.”
It’s really up to the Product Manager – User Experience Designer duo to curate and present the opportunities to the teams, and then the teams pick what they want to work on. What they pick then ends up on that two-month roadmap.
Have a product management story to share? Contact us at [email protected].
LIKE.TG 专注全球社交流量推广，致力于为全球出海企业提供有关的私域营销获客、国际电商、全球客服、金融支持等最新资讯和实用工具。免费领取【WhatsApp、LINE、Telegram、Twitter、ZALO】等云控系统试用；点击【联系客服】 ，或关注【LIKE.TG出海指南频道】、【LIKE.TG生态链-全球资源互联社区】了解更多最新资讯
本文由LIKE.TG编辑部转载自互联网并编辑，如有侵权影响，请联系官方客服，将为您妥善处理。
This article is republished from public internet and edited by the LIKE.TG editorial department. If there is any infringement, please contact our official customer service for proper handling.
