This is the second in a series of interviews that we are 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.
The following conversation is with Shivan Bindal, Director of Product Management at Procore (a California-based SaaS company that builds software for the construction industry). Here’s Shivan’s story.
How did you get into product management?
Shivan Bindal (SB): I came into product management through consulting, which is one of the more traditional routes. There are three traditional ways to get into tech product management or software product management. One route is via the engineering department. Another route is through consulting, where you do parts of all different roles, and you can choose to narrow in on product management as a full-fledged career. The third route is through an MBA program, from which you can transition into an outbound product management role.
I came in through that second option. I had a background in software engineering and I managed engineers. Then, I moved into program management as a consultant for a boutique software consulting company. I decided that what I really loved about my job was product management, day in and day out. And product management is what I’m doing now and what I absolutely love.
What do you love about your job and what is the most challenging part?
SB: At the heart of it, being more of a technical product manager, I love solving problems. Identifying problems is a big part of the job, as is figuring out what customers’ true pain points are. You need to empathize with folks experiencing pain, and then actually solve their problems and remove their frustration.
As with any job, there are also significant challenges. I think one of the biggest challenges is the fact that, as a product manager, you own something that is intangible.
Tweet This:
“One of the most challenging aspects of being a product manager is owning something intangible.” #ProductLessons
Product managers are often described as “CEOs of the product.” Well, a CEO is responsible for a staff. But as a product manager, you own the product — you don’t own the engineering team behind the product. You don’t own the marketing team that’s responsible for taking the product to market and maintaining its success in the market. Nor do you own the sales team that’s responsible for selling the product.
Product managers are not general managers, so a big challenge can be fostering a collaborative environment. You need to get the job done, but you have to do so by exerting influence in indirect ways. You have to get stakeholders across the business — both internal and external — to not only buy into your vision, but to buy into the execution of that vision over time. I think that’s one of the hardest things any product manager has to reckon with.
How do you manage conflicting priorities within your organization?
SB: As I always tell people and reiterate to myself, there’s the science of product management and then there’s the art of product management. Things like dealing with individuals, fostering collaboration, and ensuring that everyone is marching to the same drumbeat really entail more art than science.
I think you have to understand motivations when individual priorities conflict across the organization. You have to understand who’s driving the priority, what’s driving them and why they’re even at the table — why do you need them and why do they need you? Having a very clear answer to those questions will help you arrive at as many win-win scenarios as possible.
All relationships have to be mutually beneficial — what’s a priority for you needs to also be a priority for your stakeholders. If that’s not the case, then you need to reevaluate.
It’s often the case that you’re just talking to the wrong person. If you’re talking to a go-to-market specialist, they may have a harder time understanding the strategic value of what you’re working on compared to someone who has a broader view of where the company and product line is going.
But, competing priorities are always something you have to battle. As a product manager, you have to walk the line and ask yourself, “Am I right or is the other person right?” And then you have to suck it up and just do what needs to be done in order to move forward.
Another aspect of managing conflicting priorities is identifying what it is you’re really trying to achieve. In traditional scrum, when you’re prioritizing backlogs, you often have to deal with the question of whether to build new features or fix technical debt. You may also be weighing capabilities that were previously put to the side because of MVP-type release strategies.
At what point do you go back and fix things or build what you never did? Or is it better to just focus on building the next shiny thing?
I use a very simple model that some old colleagues and I came up with called ARC, or Acquisition, Retention, Consumption. The goal is to ask yourself, “What am I trying to accomplish?”
Are you trying to encourage more adoption of your product? Are you trying to get people who are using your product to use it more? Are you trying to get people who are using your product to stay with your product? These questions help me not only in identifying which priorities make sense and also in communicating these prioritization decisions to stakeholders.
What tools or software can you not live without?
Evernote is a great tool for taking notes and staying organized, which is really important given product managers talk to lots different of people — both internally and externally — about all kinds of things. Trying to keep your head on straight can be really hard.
I read Ronnie’s interview, and I agree with him that Post-it notes are also a great tool. I used to use digital Post-it notes for reminders, but I’ve since moved on to using a Trello board to organize my tasks. There’s a sense of accomplishment with the Kanban-style of task management. You can track tasks through the workflow to completion, which is really helpful.
On the product management side, we use ProductPlan for our roadmaps and to ensure we’re all in alignment on whatever we’re doing over the next three, six, and nine months.
And finally, it’s very old school and traditional, but I cannot live without the suite of Microsoft Office products. I need to be able to write a document, write a spreadsheet, or write a presentation and leverage it. These days, though, I tend to use the Google Apps more than I use Microsoft products because of their collaborative nature.
Cloud-based products are very helpful in not only communicating ideas and sharing them broadly within the organization but also in helping us on the execution side of things with our engineering squad. When we’re prioritizing our backlogs and creating our sprints, we can collaborate in real-time in our daily stand-up meetings.
Describe your organization’s roadmap planning process. How far out do you plan?
SB: We employ the Spotify squad model here at Procore, which is oriented around autonomous, cross-functional units. Our engineers, QA, user experience, and product management folks are all co-located and focused on a specific problem space, whether it’s a small or broad one. The size of the problem doesn’t really matter; it’s about the impact and the solutions.
Tweet This:
“The size of the problem you’re solving doesn’t matter. It’s about the impact.” #ProductLessons
The squads operate very autonomously. They discover problems they need to solve, then they ideate, brainstorm, and design. They operate in a safe space, where their ideas can be quickly validated with direct outreach to clients. Then they move on to prototyping and developing the solution, and ultimately integrating it into the product.
So that’s how we build products here at Procore, and our product management team members fit that model into their processes and practices. We’re very agile. Our roadmap is strategic in nature, so we know the problem spaces we want to solve over the next three, six, nine, and 12 months. We plan roughly a year into the future, so at any point you can get a 12-month overview of what we are doing.
Because we are agile, we can’t always predict precisely when a feature will be ready or when we will start working on something. I would say we have higher confidence in the roadmap items that are three months out compared to the ones that are 9 or more months out.
How do you incorporate customer feedback into your roadmap?
SB: Customer feedback is a fundamental part of what we do. We are very market-driven and user-centric. The initiatives on our roadmap should provide value either to our prospective client base or to our existing client base. In general, every item on our roadmap is something we’ve heard about from our clients.
Depending on how far in the future an item is on our roadmap, we may or may not have confidence that it’s something we’re going to pursue. When we look at a roadmap item that’s six months out, we know that there’s some customer pain behind it, but we can’t quantify that pain. We can’t identify what the real problem is because we haven’t done a lot of discovery yet.
With items that are three months out, on the other hand, the product manager has definitely been doing research — perhaps with other stakeholders in the company, either from sales or marketing or the customer success team. The goal of this research is to really understand customers’ pain points so that we can articulate them well to others in the company.
At Procore, we align ourselves around solutions and we make sure to validate those before we begin any engineering work. We do not want to invest time into anything that does not realize value for our business.
As any growing software will tell you, sometimes the problems we’re solving are oriented around success and scale. For example, we may ask: Can we continue to onboard clients at our current pace in a sustainable manner? If the answer is no, we may enhance the onboarding process to alleviate some of the manual work.
In that example, we are solving problems for internal stakeholders — customer success and support individuals, rather than external customers. Internal stakeholders are our customers in this scenario. It’s not always external customers that we do our validation work with. Feedback is an important part of everything that happens within product management, and it’s certainly part of the roadmapping process.
What are some big product management mistakes that you’ve witnessed?
SB: All the mistakes I’ve made have helped me to become a better product manager. In the past, I’ve made the mistake of simply accepting what other stakeholders say. As a product manager, you can’t do that. You have to get outside your four walls and go back to the fundamentals of problem discovery and validation. You have to validate that what your stakeholders told you is in fact a pervasive problem and that solving it is worthwhile from an investment standpoint.
That’s not to say you need to get lost in ROI calculations or total cost of ownership calculations all the time. However, you do need to ask some basic questions: Does the problem exist? Is it pervasive? Is it part of the core competence of your company or your product, such that you should invest in solving it?
If you can answer those questions affirmatively — and if you can be confident that your sample size for the validation was large enough — then I think you are in a good place to embark upon solving the problem.
What would you say is the most important skill for a product manager to have?
SB: The scope of product management is all over the board. Some people differentiate between product owners and product managers, and between inbound product managers and outbound product managers. Other people confuse program management for product management, and still, others consider product marketing and product management to be interchangeable.
So there’s a lot of confusion around the term itself. If I had to choose the most important skill for product managers, I would have to clarify whether we’re talking about internally-oriented product managers in technical roles or more strategy-oriented product managers.
Tweet This:
“The most important trait I look for when hiring new product managers is insatiable curiosity.” #ProductLessons
The crucial question is: Can you understand the product? And can you understand what the market needs are? There are a lot of must-have skills for product managers, which is what makes our role so challenging and so dynamic. You get to explore so many different skill sets throughout the course of your career — it’s truly rewarding.
The most important thing I look for when I’m hiring is: Does this person demonstrate an insatiable amount of curiosity? A curious product manager is one who will never be satisfied with just one answer.
Another important skill is the ability to recognize patterns. Can the person identify patterns intuitively as well as statistically? Can they look at a set of data or parameters, or a set of answers to questions they’ve asked, and discern a compelling conclusion? And it’s important that their conclusion is not grounded in fallacy, and that it is not supported by confirmation bias or any other sort of bias that would prevent it from being objective.
How do you stay up-to-date on product management?
SB: The most beneficial information I’ve learned has come from reading. I think reading relevant blogs and books is really important, as is routinely putting your own thoughts out there for feedback.
I think Scrum and agile principles should be applied at the individual level. One of the big things I always advise product managers to do is to hold retrospectives for themselves. Find 15 minutes per day, perhaps on your drive home, to really think critically about the day’s events.
Did that client call go well? What could you have done to make it better? Could you have asked the questions in a different way? If there was a source of frustration, what can you do next time to alleviate it?
Tweet This:
“Apply agile principles at the individual level and hold retrospectives for yourself.” #ProductLessons
And it’s also important to apply the information that you collect along the way. Reading has really helped me expand my skill set, and it has expanded the set of things I consider when I’m thinking about how I can improve myself during those retrospectives.
Another really great tactic, which I can’t speak to much personally, is to find a compelling mentor who is successful in the field you want to be in. Be inquisitive and leverage the curiosity that you inherently have — really challenge other people to help you. All product managers should be constantly oriented around improving themselves.
Have a product management story to share? Contact us at info@productplan.com.
