Bryan Reinero talks with Harsh Sinha, VP of Engineering at TransferWise, about Product Management. Product Management deals with the planning, delivery and marketing of a software product. The discussion covers how those functions are achieved, and how product management interfaces with engineering; how product requirements are derived from customer needs; how teams build product based on those needs; how the success of the product is measured; and what makes for a successful product manager.
Show Notes
Related Links
- Episode 161: Agile Product Management with Roman Pichler
- Harsh Sinha on Building an International Product
Transcript
Transcript brought to you by IEEE Software
[0:00:00]
Voice over: This is Software Engineering Radio, the podcast for professional developers, on the Web at SE-Radio.net. SE Radio is brought to you by the IEEE Computer Society and by IEEE Software Magazine, online at computer.org/software.
DigitalOcean recently launched Spaces, a beautifully simple object storage system designed for developers who want a simple way to store and serve a vast amount of data such as images and large media files, user-generated content, backups, and logs. Spaces is available for a simple $5.00/month price that includes 250 gigabytes of storage and 1 terabyte of outbound bandwidth. Additional storage is priced at the lowest rate available: $0.01 per gigabyte transferred and $0.02 per gigabyte stored. This provides cost savings of up to ten times, along with predictable pricing and no surprises on your monthly bill. Try it for free with a two-month trial by going to DO.CO/SERadio.
Bryan Reinero: Welcome to Software Engineering Radio.
[0:01:00]
My name is Bryan Reinero. Harsh Sinha is VP of Engineering at TransferWise, an international money transfer platform. Harsh was Director of Product at PayPal where he led the product strategy and development of PayPal’s mobile apps and software development kits. Harsh also spent ten years at eBay, starting as a software development intern and rising to head of Software Engineering. Harsh is also an advisor and investor in early stage startups. Welcome, Harsh, to Software Engineering Radio.
Harsh Sinha: Thanks for having me, Bryan.
Bryan Reinero: Today we’re discussing product management, which deals with the planning, delivery, and marketing of a software product. We’ll discuss how those functions are achieved and how product management interfaces with engineering. To begin, I’d like to ask what is product management?
Harsh Sinha: So, product management is a multifaceted discipline. Basically, the way I think about product management is all the tasks needed to take an idea, –
[0:02:00]
a fledgling idea to the strategy of execution of that idea, the execution with the team to bring the product live to the customer, and then the lather, rinse, repeat of that process where you learn from the customer and then iterate on the idea and improve the product. So, the ownership of that entire process is usually done by an individual in a team who’s called a product manager.
Bryan Reinero: So, it’s a function that’s not just a one-time function where you’re dreaming up new products: It’s, as you say, iterative, that it’s a cyclical process of planning?
Harsh Sinha: Definitely.
Bryan Reinero: What are the responsibilities of a product manager?
Harsh Sinha: So, I would break down the responsibilities of a product manager into three main themes. The first one would be, I would call, inspiring. Inspiring from a perspective of having an idea. If you’re working at a company – let’s say it’s a startup or a large organization – usually the company has a larger goal or a mission statement, or we can call it a vision of the company.
[0:03:00]
From there, you as a product manager have to think of ideas, work with the team, work with the customers to understand: What do you need to build to add more value and align the product towards that vision of achieving the goal that is initially set by the company? And that is – requires a lot of inspiration, getting inspiration from customers, but then also inspiring the team within to build this product.
And under inspiration I would say there’s a lot of work around understanding the market, understanding customer needs, understanding how your current product is placed along with other products and competitors of the market, and what is the real, true value proposition that you’re providing to the customer?
So, the way I think about it is in this phase you would think about answering the questions, which are “What is the problem you are solving?
[0:04:00]
What does the customer – why does the customer care about this problem that you are solving? And why does it matter to the customer? And who does it matter to?” Along with this in the inspiration process you would also have to define success and fail criteria for everything that you launch. So, if you are going to run an experiment to test whether a new feature is going to add value or not to the customer experience, before you even think about writing your first line of code or getting anything done you have to define and work with the team to understand what would be the success and fail criteria. So, that is kind of the umbrella of the inspiration part and thinking about the ideation of the product.
The second part which is a big role that a product manager plays in a team is prioritization. So, product managers tend to get feedback from all different places. They get feedback from the customer, as I said before. They look at analytics and what the market’s doing. They look at what the competitors are doing.
[0:05:00]
They also get feedback from the team as to what’s possible to build and not to build in the overall product life cycle. And taking all this data and feedback, helping the team to prioritize as to what are the next top things to build, what are the next top things to get right as a product is evolving is a large part of the product manager’s role. It doesn’t mean that the product manager goes into a conference room by themselves or in a cube by themselves and just puts their head down and prioritizes across an Excel spreadsheet, but it’s more about having a dialogue and having the harder conversations with the team based on scoping, sizing, the possibility of building what is desired right now in the market versus what the technology can do. All of that input has to be taken into helping eventually the team have that conversation to come out with a prioritized list of things to do.
And the third part of the responsibilities of a product manager, I feel, are execution. So, nothing gets built with just strategy. Execution is – we need a strategy for lunch, dinner, and breakfast.
[0:06:00]
So, execution is a very critical part of product management. And from my perspective the big things that product managers tend to execute on and have to be good at is of course defining the product specifications based on the first two parts of the ownership that I just described, which was inspiration and ideation and then prioritization. The second part is not just defining the happy flow but also defining the unhappy flow and the edge cases when the product would not work or would not work as always desired. The third part is kind of being the project manager, to an extent, of making sure things are getting delivered and if there are blockers that are impacting the team – some of this could be outside the team – then helping drive those conversations cross-team, across the company to make sure those blockers are removed so that the team can move forward. And finally, in the spirit of the learn – build-measure-learn process, making sure that analytics are set up correctly, –
[0:07:00]
are read correctly, interpreted correctly to determine whether the experiment, the learnings are a success or a failure, and feeding that back into the iteration cycle so that the product keeps continuing to be iterated on and improved.
That’s how I see the – what the responsibilities of a product manager are.
Bryan Reinero: I see. So, there’s these multiple phases that you have to discover what the needs of the customer are, then again articulating those needs to the team, the engineering team to be executed, and then the job is not done at that point. You’ve got to help see it through to execution and then deployment. And then, even at that point the job not done: You need to gather metrics to determine success, degrees of success, and then start the process over again.
Harsh Sinha: Yes.
Bryan Reinero: So, an interesting question would be: Why should this job be done by an individual product manager?
[0:08:00]
Are there cases that would be easier just to have customers talk to the engineering team directly?
Harsh Sinha: So, that’ s a very interesting question. At TransferWise specifically we tend to do this. So, we believe in having as few people between the customer and the engineers as possible, so we have set up cases where engineers take customer calls direction working with our CS agents. Engineers answer e-mails and chats directly. And the idea here is to not basically have the engineers become CS agents or become the person who is just talking to the customer but actually try to give the pain – the feeling of the pain that the customer is going through to the engineers. And that way, when the engineers are building something and building the product they understand the why, why they are building a part as they are shipping stuff.
[0:09:00]
That said, there is only so many cycles in a day and so many hours in a day and engineers do have to execute and write the code and develop the systems that drive the product and drive the experience. And from an efficiency perspective also it is good to have one person or a group of people who can actually collate, talk to different folks, whether it’s customers, whether it’s partners, whether it’s other – if you’re in a B2B business, other businesses who can then tell you what it is that they want and then distill that down to a few larger themes that then the team executes on.
Also, there is a little bit of a skill set question here too. For most engineers it is not always natural to be able to get out in front of customers and be able to speak their language and understand the specifics of the requirements that they are asking for because engineers a lot of times tend to be a little bit more involved in the technical details of things. So, a product manager can also act as a good translator in the medium to convert those customer voices into actual internal implementation specifics.
[0:10:00]
But overall, we do push TransferWise to have engineers speak directly to customers.
Bryan Reinero: Yeah, I imagine that avoids getting some items getting lost in translation or having the needs or pains of the customer somehow changed by a game of telephone.
Harsh Sinha: Definitely. That’s the main reason why we do this, yeah.
Bryan Reinero: So, generally speaking, it would be then for – a mistake to think of the product manager as a person who should be filtering or somehow being the conduit of conversation from the customer to the engineering team. It’s always – it sounds like it’s always better to have that kind of customer access, or at least being able to understand the customer’s needs and pains.
Harsh Sinha: Yeah, definitely. So, as I said before, I think the product manager’s role is to clarify and explain the why and the what of the problem and then let the engineers figure out the how.
[0:11:00]
But how do you do that in a manner such that you don’t take away very specific details that the customer shared, so that the voice of the customer really carries through to the engineering team? It’s important.
Bryan Reinero: Is there a document, a formalized format that a product manager or product management should provide that articulates the customer pains? What – in this process of discovery, what does the product management provide to the engineering team to clarify and categorize the customer pains?
Harsh Sinha: Yeah. So, I’ve worked in different size organizations and build different size teams, so I think it varies from organization to organization how structured this is. So, I’ve worked in teams where product managers write down specifications in Word documents and then –
[0:12:00]
it goes through multiple reviews and peer reviews before it makes it into the engineering teams’ in boxes. It seems to be a much more traditional approach, and I’m sure there are organizations running that way even now.
I still remember back in the day when I was at eBay in the early days, there used to be a template of a document called a PRD: a product requirements document. And that literally was the template used by every product manager in the organization that would be answering a bunch of questions on every feature that is proposed to being launched, and it was a full-on 40-pager kind of document where you would have screen shots or wireframes and everything specified in that. And then, this would make it to the engineering manager or the engineering team, and then they would go through that and interpret the document into an ERD, which was an engineering requirements document, which was even longer and which talked through – took the product requirement document and –
[0:13:00]
built technical implementation details to that before it actually went into the full implementation process for the product.
Now, what I just spoke about is a much more waterfall life cycle of developing a product. This is when we used to take a few months to ship a product, at least. Nowadays, the way we see teams working and product specifications working are much more higher level. So, I can give you an example of how we work on this in TransferWise.
In TransferWise we tend to run smaller product teams. So, we usually have one product manager with about anywhere from three to six engineers on a product team. And these product teams are full stack, so we’ll also have CS people, CS representatives, customer support; operations representatives if we need to have a business partner or a banking person given we’re in financials. That person is also on the team. And overall, the team plans together, prioritizes together, and understands why they are building what they’re building.
[0:14:00]
And the product specification usually starts off in a ticketing system like Jira, which would be starting with an EPIC, which is where you specify what are the major tasks and the major – what is the main theme that you are trying to achieve here, and what is the main value prop. And from there, then, the EPIC is broken down into specific tasks which are iterated on by the product team.
So, that’s how basically it’s set up now. So, having smaller teams and usually one- or two-location teams that work well across Hangouts also helps drive that conversation where you don’t have to write as many documents but really there’s an iterative process, so the feedback loop is going faster.
Bryan Reinero: So, it – one thing I noticed you said is that the financial team may be part of the product team. Does that mean that the team that product managers or product management interfaces, that the product team is a cross-functional team?
[0:15:00]
Harsh Sinha: Very much. At TransferWise we are very – when I say “full stack” that means a cross-functional team of having all disciplines that’s needed to get that part of the product live.
Bryan Reinero: Is that difficult to achieve and still maintain a small team?
Harsh Sinha: I think it varies. But in general – so, I’ll give you an example of customer support. So, of course, if you launch one part of the product – let’s say TransferWise has – we have a product which allows you to move money between the US to the UK. So, there will be a core team of customer support and individuals who are supporting that route. So, we would not have the entire team in the standup and the planning sessions, but you would have a representative, one representative from that team who understands the scope and the challenges that the customer support team and the customer interactions is creating to give input to the team. So, we tend to have some representatives for larger teams, but then the core engineering team and product team will be there. So, usually there’s one product manager and a few engineers.
Bryan Reinero: I see.
[0:16:00]
So, it sounds like the process – each iterative cycle of managing the product, developing the product, the customer is an important aspect of the process, especially for the responsibilities of product management. Why is the customer so important?
Harsh Sinha: I mean, I guess in this product-driven world the way – we are here to solve customer problems. If we just are building stuff without getting input from the customer, then it’s probably more of a hobby project or a project where it’s – you’re trying to do something where you’re trying to learn a new technology or do something which is very specific to your needs. But given that we are here to solve customer problems, having the customer’s voice and the customer input and feedback throughout the process to understand what’s working, what’s not working is super important, as teams can drift very quickly based on their own assumptions.
[0:17:00]
So, one thing we see quite often is anecdotal evidence being taken as the direction – as real evidence. It’s the whole thing of people thinking their problem is the biggest problem to solve. So, if you are moving money between US and UK and you see a specific behavior that is true for you and your friends, ten friends around you, you think that the world is like you, as opposed to having feedback from the larger group of customers moving money on transfers between US and UK and then taking their verbal feedback and quantitative scores around the feedback that we request and making decisions on that. So, that’s why it’s important to make sure we don’t get the bias of just – you know, the unconscious proximity bias or the context of just working in your own – solving your own problems.
Bryan Reinero: And in the case that a new product is being developed, how do you get that feedback when you don’t yet have customers? You’re maybe exploring whether this project is feasible.
[0:18:00]
How do you understand who your customer might be?
Harsh Sinha: Yeah, that’s a very good question. So, new product cycle is a little different than iterating an existing product. Usually, again, you would start from the basics, like I mentioned before. So, you’re trying to understand: What is the problem you are trying to solve? And why would a customer care that you are solving this problem? Why does it matter to the customer? Who are the other people that are solving this problem? Is it actually – are you solving problem number 40 on their list, as one of my professors from Berkeley, Steve Plank, would say, or are you solving problem number 1, 2, 3? And it’s very important because, as I said before, a lot of times we tend to think if we have this problem, a specific problem, that is the biggest problem to solve.
So, whenever we’re doing new product development there’s a lot of time you will spend around researching whether it actually is a problem in the market that the market requires. Is it a big enough problem that the market needs to be solved currently?
[0:19:00]
And one of the things that you look at is to see how are customers solving their problem right now? What is the offering that exists in the market right now? And then, you try to think about “Could I build a product which is an order of magnitude better than what exists in the market?” This is where you hear things like “Is it 10X better? Is it 50X better?” But the idea is still the same, whether it’s 10 or 50: Is it an order of magnitude better, that solution that you’re providing to your customers, than what exists in the market? If it’s only 20 percent better, if it’s 10 percent better, the probability of a customer switching or changing their entire workflow is be very, very low, and it can be a very, very uphill battle to acquire uses.
So, once you’ve done this kind of thinking and understanding what the market is – “What is the problem you’re solving? Why would the customer care? Would they care enough to switch?” – that’s when you start defining the success and fail criteria. You start thinking about what the flow would be. You start doing certain bits of user testing. So, this is more qualitative look where you develop wireframes and mocks and you try to get out there and talk to potential customers.
[0:20:00]
So, it’s very – in that process you also identify who your potential customers would be. So, getting out there, buying somebody a coffee at Starbucks and sitting down – if it’s a consumer-facing product – and actually working through the process of understanding, explaining the product to the customer, and seeing if they’re getting it. Do they understand the value proposition? Would they think that this is something that they would use? Would they think that this is something they would pay for? Those are the things that you try to iterate and learn very quickly in the early phases without even building any product or any tech or any code.
And from there, then, of course you get more evolved. You start doing some basic prototypes and you throw something up in a small application and see how people use it. Drive some traffic to it. That’s kind of the iteration of a new product process.
Bryan Reinero: So, in the idea of user cases, is that something that would go in the PRD – what would be some of the things that I would find inside of an example PRD?
[0:21:00]
Harsh Sinha: Yes, use cases would definitely be things that would go into a PRD. Just a general flow of what are you – what’s the problem you’re solving and how would the customers solve that problem with the product that you’re building? So, that’s definitely something that would go into the PRD. That would include use cases, edge cases, defining for each use case what would be the success/fail criteria. And then, going deeper into how would you even set up analytics: What are the things to track to make sure that eventually as the product goes live you know what the parameters were and what the markers were or what the attributes were that you were testing for? How is that fed into the reporting engine? All of that stuff would be defined.
Bryan Reinero: And is it important to have a description of the customer – like, a profile – in that document as well?
Harsh Sinha: Yes. So, different teams do this differently. Some people define it as customer personas. Some define it as an ideal user. But having some kind of description of who you are solving the problem for is very important.
Bryan Reinero: So, we have the PRD that describes the use cases, the customer.
[0:22:00]
Can you give me some examples of the analytics that would be useful? These analytics would be metrics for measuring the success of the product. What kind of things would be – would they be looking for?
Harsh Sinha: So, some of the basic analytics would be things like – let’s say you started a new product. You’re trying to understand how many people are landing to see that product, or are seeing the product landing page, for example, or home page. Or, if it’s an app, then the home screen. How many people are actually visiting, as I would say, to explore the product? And from – so, you would start looking at non-locked-in or session-based visitors, and then you would basically build out a regular conversion funnel – so, if your product is something that requires in the end somebody to take an action and there is a whole process of converting that person from a visitor to an actual signed-up and registered user to actually doing that first transaction.
So, I’ll give you an example of TransferWise again.
[0:23:00]
For us, a user is a user once they’ve created their first transfer and completed their first transfer. That means money has moved on the platform. If you’ve just signed up as a user and you’ve created an account, given us your e-mail account and set up your account, but you haven’t created and funded your first transfer and the money hasn’t shown up on the other side, we don’t count you as a user yet. So, now through this whole process there’s this conversion funnel that we look at. So, we look at somebody who lands on the – on, let’s say, our website landing page as a visitor. Then, what did they do as they started with the page? How much time did they spend on the page? Did they scroll around? Did they interact with certain components, certain elements of a page which explain what we do, how money moves, what is the value proposition that you have? We have a calculator on our home page which tells you the basics around if you were to move $1,000.00 to pounds how much money would you get at the end on the other side in the UK?
[0:24:00]
What would be the fees? So, did they play with that calculator? If they did, that means there is some intent, there is some engagement.
And from that process then you would start seeing where do they fall off, if they do fall off and leave the platform before they complete the first transfer. So, did they fall off if they clicked on “Get started?” – which is on our calculator – which takes you to our signup page. From there, did they go into that page and fill out the user name and e-mail address, give us their e-mail address, and set up their account? Then, did they go into the flow of creating their first transfer, which is a step-by-step flow of giving us details of how much money you want to move, what is your account information, what is the recipient information? And just tracking this entire process of making sure where the user is, where the user drops off. Did they have difficulties in errors of filling out any of these fields? How much time did they spend? These are some of the metrics that you would calculate to understand how the product is doing.
Eventually, the success or fail of this product would be things like, as I said before, –
[0:25:00]
how many users of the total number of users, visitors who visited the site converted, as in exited the funnel with converting to create a new transfer? So – and then we start measuring metrics like “What is a conversion rate? Is it ten percent? Is it 20 percent? Is it 35 percent?” And from there, then, you understand what are the things you can improve to increase that conversion rate? So, you go one level deeper into some of these analytic numbers that I talked about, metrics that I talked about, whether they’re getting dropped off at the registration page, did they get an error, did they spend a lot of time on the home page but then dropped off there? They then track several components. That’s how you look at it.
Bryan Reinero: So, it’s probably of course the case that each different product is going to have a different set of metrics, but generally speaking, the reason that you’re collecting this data is to improve the product, understand the user better, and see where the product is fulfilling the needs of the user and where it’s failing to.
[0:26:00]
Harsh Sinha: Yes. Exactly.
Bryan Reinero: So, this would also lead me to think that the – as you gather these metrics and process this information, that gets fed back into the PRD and it may change the user stories that you originally started out with. The PRD becomes a living document – there’s a feedback loop in there, is that correct?
Harsh Sinha: Yes. It depends again on the organization and how – what processes exist in the company. So, that’s why at TransferWise we don’t do as much PRDs but we work more in a more agile manner with EPICs and tasks. But then, the idea being the same, that given the feedback and the analytics, what the numbers are showing, this feedback would flow back into new requirements, whether it’s in the form of PRD iteration or it’s in the form of a new EPIC, new stories, new plans. It varies based on the company.
Bryan Reinero: So, yeah, it seems like the process is designed to – it sounds like the process is designed at –
[0:27:00]
TransferWise to be able to iterate quickly and reduce friction so that rather than being on a periodic or – you’re cyclical in nature but you’re not periodic in nature.
Harsh Sinha: Yep.
Bryan Reinero: It’s more of a continuous –
Harsh Sinha: Yes. And also, we push our setups such that once a product’s live – even in the early stages of the product being developed, engineers are much more closely involved with understanding the whys, just like a product manager would. And ideally, the way we iterate then after the product is live is the engineers are very much into the analytics and the data too, so then they can read the data and try to make assumptions and make inferences and understanding what’s working and what’s not working. Because a lot of times we’ve seen that with that input the iteration speed can be even faster because the engineer has actionable data to interpret and work through and then iterate the product quicker.
And in that case the product manager then takes the step of – takes the seat of, role of coaching the engineer and interpreting the data and moving along the product.
[0:28:00]
And usually, there’s more engineers than a product person on a team, so if you think about every feature that’s live, if there are more engineers who take ownership of this feature being live in production, the iteration speed increases because it doesn’t have to go to one person who’s a product manager who’s interpreting all the data and giving instructions to the team on how to move things along.
Bryan Reinero: That’s an important distinction. So, in the case, then, that this feedback is arriving, the analytics – the team is processing these analytics, that the tickets are generated, is there a triage process? Or, that goes directly back into the backlog? How is that processed?
Harsh Sinha: Yeah, I mean, usually that’s how teams would operate here. Again, we don’t believe in having – we believe in solving the problems that the teams have. So, every team kind of has their own slight modifications of the process as opposed to having one single process for the entire company.
[0:29:00]
So, the way most teams in TransferWise work is the feedback would come in; that would go to form type of a backlog in the form of tickets. And then, usually teams run on a one-week or two-week cadence – most of the teams here run on a one-week cadence – and before the team would go into planning for what they’re going to achieve or do on Monday morning for the week, usually the product lead and the engineering team lead would get together and do a quick triage so that they don’t spend as much time in the planning session with this large group of people explaining and discussing some of the prioritization work. But they will pick up things that have already been noteworthy from the previous weeks and bring that into the backlog and drop some of the other stuff that may not be as relevant, so that way you have efficient use of the time doing planning and iteration for the rest of the week.
Voice Over: Auth0 is the easiest and fastest way to implement authentication and authorization architecture into your apps and APIs.
[0:30:00]
Allow your users to log in with username and password, social and enterprise identity providers such as Facebook, Twitter, AD, or Office 365, or without passwords using Slack or WhatsApp. Getting started is very easy. Use one of more than 140 SDKs and add a few lines of code. No credit card required. Get the free plan at Auth0.IO/SERadio. That’s A-U-T-H-the-number-zero-dot-I-O-slash-SE-Radio. Auth0 is trusted by developers at Atlassian, Mozilla, Optimizely, and Financial Times. Try it out at Auth0.IO/SERadio and get back time building core features.
Bryan Reinero: Can you tell me what a product roadmap is? And given your process, do you use a product roadmap?
Harsh Sinha: We have – the definition of product roadmap for us is a little bit more like a vision document, I would say. So, every team, again, operates a little differently. We launched something recently called the Borderless Account.
[0:31:00]
So, the Borderless Account is a new type of virtual bank account that we created where it allows businesses and consumers to hold balances in different countries in different currencies easily, and then you can get paid and pay out as a local person in all these countries. So, people across 20 different countries can now just – sitting in their own country – open an account in the – with the USD currency or a UK currency, and they also have local US/UK bank account specifications. So, you could be sitting in India and you could have a US bank account with a bank account number and a routing number. And now, if you’re a freelancer, then you can get paid locally in that bank account number and routing number, which is a big deal for a lot of people because if they’re doing business cross-border, then when the clients are paying that gives – when they issue the – when they give the invoice and the local US routing number and account number they seem more legitimate.
[0:32:00]
They are more trustworthy. And also, the payer doesn’t have to deal with – dealing with cross-border transfers and stuff like that.
So, this process and this product is pretty new for us. We launched it about five months ago. And for that, there’s much – there is a bigger product roadmap, which is like a vision document, and then that breaks down into different phases. And in those phases, as you go out further in let’s say phase one, phase two, phase three, the phase three would be more nebulous with higher level problems that we’re trying to solve for the customer. But then, phase one, phase two, which we would be right now in, would have – be linking – would be linking into this kind of backlog and this kind of Jira dashboard that we were talking about where you have all the EPICs defined and more of the near-term tasks defined clearly.
Bryan Reinero: So, it sounds like the product roadmap is perhaps more important for projects that are just kicking off, or at least a new phase of an existing project or product?
[0:33:00]
Harsh Sinha: Yeah, I think it’s fair to say – I think the vision document definitely is very, very important as you start off a new phase or a new product. And it still is a living document, so as you evolve the product it should have some of the changes and iterations in it. But it’s very, very important in the initial phases to understand the entire scope of what you’re trying to build and what problems you’re trying to solve.
Bryan Reinero: So, in each of these phases – obviously, I guess, the phase is marked to some area of time, phase one being the near-term goals, phase two midterm goals, phase three far horizon – what kind of items would be inside of each of these phases? What would you describe in each of these portions?
Harsh Sinha: I guess that’s a – that’s very elemental to the product and the implementation strategy. So, in our world, given we are a fast-moving consumer product, –
[0:34:00]
usually the near-term – like, phase one would be if there’s a new launch product, then it would be the basics of getting something up and running as an MVP – so, minimal viable product, which just has to be a useable product that solves the core customer problem. And it’s very important to get that out to understand how would a customer use it, how would a customer find this product? And knowingly, that we know there are a lot of features that are not there yet, that all the bells and whistles aren’t there, but it’s a useable product for those people who really have the problem in the market right now the most, and they might still pick it up and use this product in its MVP form because they’re willing to take the pain of using this because the alternative is so bad.
And from that, then, you would get more feedback from these early users and early adopters to see what is working, what is not working, and then incorporate that feedback into the iterative cycle. So, that could be a larger phase two, phase three, and that’s how it would go.
[0:35:00]
Bryan Reinero: So, I guess an important aspect of defining what the MVP is something that’s practical, useable, valuable to the customer or user, but also don’t go too crazy because you want to get it out there to get the feedback from the customer. So –
Harsh Sinha: Yes. Yes, definitely.
Bryan Reinero: So, who is the roadmap written for? Who is the audience of the roadmap?
Harsh Sinha: That’s an interesting question. I think it varies a lot across companies. In most cases the roadmap consumer – or the audience is the team – so, the team that is going to implement and build the product. But I think it also spans outside the current implementation team. So, it could be other teams that possibly need to get – need to help you get this product to the market. It could be other teams who need to understand the impact of you building this product on their roadmaps or on their product.
[0:36:00]
And in a lot of larger companies, a lot of times the roadmaps are also – the audience could be different stakeholders or senior leadership. But usually, the roadmap is – the audience for it would be the internal company employees who are helping build this product. So, it’s very, very important that the team at least buys into and understands – buys into the roadmap and understands the nuances of what’s in phase one, phase two, phase three. And then, it expands out from there. The further you go away from the team, the roadmap probably gets more higher level for people.
Bryan Reinero: So, some of those audiences, it sounds like because product management is a cross-cutting concern, if you will, or spans so many different teams that the roadmap that’s developed should take into consideration, is there a support team or customer success team that needs to understand where the product – what product is going to be coming? Certainly, I would imagine that Sales would like to know the forthcoming features and what the product is going to be. That’s useful for them as well.
Harsh Sinha: Definitely. Yeah.
[0:37:00]
Bryan Reinero: So, anybody who has involvement with marketing, I would imagine, also is another important audience of the roadmap.
Harsh Sinha: Yeah. So, as I said, different teams who are not inside the implementation team but possibly are impacted, their work is impacted – either what they are building is impacted, or what they are selling is impacted, what they are marketing is impacted, what they’re supporting – as in supporting customers calling in – is impacted. All of them would be consumers of the roadmap and they would like to know where the product is right now, when it’s going to launch, what are the features, all of that.
Bryan Reinero: So – and again, taking a look inside of that product roadmap, we would see each of these phases – I guess it’s different for different cultures, different companies, different organizations, but would it be like a list of features at each phase? Would it include the user stories? Does it need to be that detailed?
Harsh Sinha: Product roadmaps, I think, operate at a little bit higher level than, say, what we’ve been discussing before around PRDs.
[0:38:00]
Some of them for a new product might have user stories, or at least personas, to give an overview, a high level overview of what is the problem you are solving. But in general, roadmaps from there very quickly go down to “Here are the main things that we are going to launch,” and those things are basically capabilities that the users will be given after the product launch. So, will they be able to do X, Y, and Z? That’s where the roadmap covers, the level of depth the roadmap usually covers.
Bryan Reinero: We’ve done our customer interviews. We’ve done our research as to what the product should be and who we’re servicing, what users we’re servicing with the product. As we go into implementation, the agile team, cross-functional team that is implementing the product – or, implementing the project, a lot of these functions seem to be fulfilled by the product owner of a scrum team. Is there – is the product owner the same thing as a product manager? Same functions?
[0:39:00]
Are there circumstances that they’re different people? And if they’re different people, how do they interact?
Harsh Sinha: Usually, in my experience so far the product owner and the product manager are the same people. In very rare cases, if for example it’s a very technical project or product change, it might be that the change is owned by the technologist in the team or the technical leader in the team. But in the usual cases I’ve seen, it’s the ownership lies on the product manager to eventually bring the product to production or to the live environment in front of customers. This is true for both consumer products and B2B products that I’ve seen.
Bryan Reinero: In the case that the product management is being achieved by the product owner, what degree should – let me rephrase that one more time, if I may. In the case that the product manager is interfacing with the product owner, what interaction would those have with regard to prioritizing a backlog, let’s say, for instance?
[0:40:00]
Harsh Sinha: So, prioritization is a very big role for a product manager to do well in the team. The way we operate, and the way I’ve seen teams in general operate, prioritization is a two-way conversation. It’s definitely not something that’s just done by the product manager or product owner. The way it works is basically having an open conversation around what is the customer’s expectations – so, that’s one of the inputs that goes into the prioritization process. What is the customer’s problem that we need to solve first before we get to the later problems? So, trying to define the initial MVP.
But then, also, there is quite a bit of input around what is technically possible to build? So, it could be the case that while there is a big feature that the customer is asking for, building that specific feature in the initial version might be technically much more challenging or might require quite a few – quite a bit longer than the other features. And it’s this song and dance that happens between the technology team, or the dream team, and the product team,
[0:41:00]
– and – to understand to what will be the initial prioritization to get something out that is still useable, that customers would use and we could learn from and take the feedback.
Bryan Reinero: I just caught something that I thought was pretty cool. You said “the technology team and the dream team” – the dream team being those that would request new features and have a stake in the vision of the product? Is that a correct to take that…?
Harsh Sinha: Sorry. Maybe I misspoke. I meant the engineering team. I did say “the dream team.” But I guess that’s true: There would be a dream team dreaming the vision.
Bryan Reinero: Really interesting. We have a process for developing a product. We have a process for implementing the product and even getting feedback in metrics to see how it’s performing. How can product management – it has some responsibility for the business success of the product, it seems to me. Would you say that that’s correct?
Harsh Sinha: Yes.
Bryan Reinero: So, in tricky situations where something kind of comes out – there’s a new customer; they would like functionality and –
[0:42:00]
perhaps they would like this functionality prioritized in the backlog or the roadmap or it’s something new and it’s a big account – I can see that there’s kind of an inherent conflict with needing to fulfill the needs of the customer, but also, as you say, that song and dance of – the balance of what’s technically achievable. How can product managers help mitigate that conflict or deal with it when there’s things that come out of left field that disrupt the plan?
Harsh Sinha: Yeah, I think this is one of the bigger struggles that a product manager has to deal with as they work with the team and build a product. So, I don’t think there’s one specific way to handle this. I mean, you obviously have to weigh the pros and cons and the tradeoffs for every discussion, decision. One of the things that I’ve seen, especially in the case of what you’ve specifically described, which sounds like – more like a B2B case, like a consumer product, –
[0:43:00]
but more like a business product or a SAS product, where you can have one large customer who could really just impact the entire growth or revenue, or the growth of the product overall. In this case, I think it’s important to try and see whatever you do build today for this customer, is that actually going to be used by the customers? I think that’s a very big litmus test.
Having seen a lot of products – and I’ve seen this in my career – that tend to make optimizations or changes for one large customer – and large customers also can make a lot of promises, and then you implement something and something goes out and then they might still move on to some other product or they might not see the value of what you built as much as you initially thought or promised.
So, it’s important to make sure in the larger scope of the vision of the product or the roadmap that you have and the other customers you have, how does this, –
[0:44:00]
I guess, spending a lot of time for this specific team to build this new feature, how does that impact other customers? Could you turn around and sell it to others? If that’s the case and that’s true for a decent majority of your customers, then I think it still is a better conversation to have than basically just selling and disrupting an entire running product team’s roadmap for one specific left field use case.
But I guess, as I said before, it’s a pro and con analysis, how much – like, in TransferWise’s case, for example, we are obviously very driven by how much volume our platform is pushing and how much – how many users we’re bringing onto the platform. So, it would be a tradeoff to, say, if we wanted to do – if we were to do X as opposed to A, B, and C, which was already in our roadmap, how much time would it take? What would you have to drop? And what is the value that we perceive of A, B, and C bringing to the business as opposed to doing X?
[0:45:00]
Bryan Reinero: And probably in the next retrospective, after having gone through a situation like that where a pivot needed to be made to facilitate a business need for a potential customer, in the retrospective you would probably examine that and say, “Could we have mitigated such a thing by being maybe a little bit – check our alignment with our customers? Are we doing the right research?”
And I would also imagine that the benefit of having the customer interact with engineers, reducing that barrier, means that the engineering team can also be able – they’ll understand this requirement, that it won’t feel like it came from left field and they’re able to pivot a little bit better because they do understand that customer need.
Harsh Sinha: Definitely. So, yeah, that’s very, very true. And that’s why we believe in getting engineers closer to the customers and customer problems and understanding the why. The big part here is also because when you’re building that part of the system, –
[0:46:00]
writing that code, if you kind of know that this is the kind of requirements that might come in the next five, six, eight months, then you think about that as you design these systems to be able to be extended and to be not required to be very hard-coded or built for only one specific use case.
Bryan Reinero: Now, it’s often said with regard to both the responsibility and maybe even the role of product manager, product managers are often said to have a lot of influence but not very much authority. What does that mean? Have you heard that expression before? And what does that mean?
Harsh Sinha: Yes. Actually, it’s funny. I have heard this expression of the product managers of the team, and I actually don’t believe that’s very true in a lot of ways. Usually, the CEO of a company, for example, has a lot of authority in the company and can make hire and fire decisions. In a lot of ways that doesn’t apply for the product manager.
[0:47:00]
The part which might be true is the inspiration piece. So, usually, in a lot of cases in most companies the CEOs tend to be the people who have been the initial founder of the product or at least are seen as the inspiration who’s driving the requirements and the strategy at the overall company level and the company vision. And from that perspective I do think that a product manager’s biggest role is to inspire and lead from – inspiring and influencing.
So, there’s this thing that we talk about at TransferWise. The engineers we hire, they are teams called product engineering. It’s not just engineering. And as I’ve said before earlier in the podcast, we push engineers to get closer and closer to the customers to understand the whys of what they’re building. And engineers in our company have the right to walk from their team or vote their feet when they believe that what they’re working on doesn’t anymore help the customer, the TransferWise customer as much as working on something else.
[0:48:00]
So, in that setup the product manager’s role is even harder because they need to explain and have the voice of the customer front and center and really inspire the engineers to be doing the best work in moving this product forward. And I think that’s where having the ability to be able to do storytelling or to be able to be very clear in communications and bring the voice of the customer into the room and being able to explain the why and the what is very, very important, because you don’t have authoritative power usually across your team.
Bryan Reinero: So, that’s interesting, that because especially in your case the engineers can elect to participate in a project, it’s the case that a product manager or product management should not only expect questions, maybe healthy in arguments about the product and the features, but also invite it as well.
[0:49:00]
Harsh Sinha: Yes, very true. In fact, if you’re not having a healthy discussion or a debate about what you’re trying to build, then maybe you’re not getting enough people interested into the problem that you’re trying to solve, which eventually would lead to possibly not having a lot of people working on it with you.
Bryan Reinero: So – and that aspect too, that healthy debate, that also implies that there’s probably some soft skills involved with this role and responsibility, that in order to keep the debate healthy and productive and – not being a personal argument but maybe a more lawyerly argument, for lack of a better term, you’re arguing for a solution, not for a position, is what I’m saying. That that requires a certain set of soft skills that are important.
Harsh Sinha: Yeah, definitely. I mean, if you look at product manager, successful product managers, they’re definitely very good – they’re high in EQ and they’re very good on being able to assess a situation in which different people are interacting and being able to move –
[0:50:00]
the conversation forward around solving a customer problem and the solution and not being really held onto their viewpoint only.
Also, overall, product management, as the company grows – and different companies are different about this, but in a lot of larger companies the role of a product manager is also having the – being the ear on the ground for the team to understand what’s happening across the company. If it needs other teams to help do something to get your product launched, then being able to, for lack of a better term, negotiate that that gets picked up in the roadmap, and being able to explain the same aspect of why this is important for the other team to do for the company and for also how it aligns to the larger goal of their team.
So, there’s a lot of soft skills and a lot of back-and-forth conversation that is – conversational skills that are required in general, and understanding how people are motivated and teams are motivated to drive along the same path for the same vision.
[0:51:00]
Bryan Reinero: Many product managers are from engineering. They may have been a core contributor or an individual contributor at some time. What kind of pitfalls with that particular career path – or rather, not pitfalls but difficulties might somebody have when they transfer from an engineering – a purely engineering role into a product management position
Harsh Sinha: Yeah, actually, I had a similar role, so I can walk you through my experience. So, the biggest thing – so, I think actually some of the best product managers are ex-engineers. And I think the reason for that is because some of the things that a non-technical, non-engineering product manager might face is the – is not understanding what goes into building a product. Something that might seem very simple on the front end from an experience perspective might require quite a bit of complex setup in the back end. And usually, you see this conversation go pretty poorly when people say – like, a product manager might be saying, “Hey, it’s so simple.
[0:52:00]
It’s like two pages and two clicks. Why does it take so much time?” Or, “That company can do this and they launch it faster than us. What’s going on?” And that basically shows that the product manager is not understanding – in a lot of cases, it shows that the product manager is not understanding the nuances of what’s problematic or tough to do in the technology infrastructure of that specific company or product.
So, I think having a technical background definitely helps you get closer – get a closer understanding of what it takes to build, but also helps you be in the good strides of the engineering counterparts who are going through that process of building in that specific infrastructure.
The flipside to this is if you move from engineering to product management and you are now helping drive some of these conversations, you have to be careful to not be very prescriptive to your engineering team because – just because you did it before and you would do it in a certain way, that doesn’t mean that that’s exactly the way that the team thinks that they should be implementing those changes too.
[0:53:00]
So, the first thing I would say is while it’s good to know how your product and system works, you need to be careful that you actually do pull yourself out of the specific implementation details on a day-to-day basis as time goes by, because technology stacks evolve, technology products evolve very quickly. So, what might have been true if you moved from an engineering individual contributor role into a product manager role, what might have been true on day one, day two of you moving, the system might have evolved in six months that it might not be as true anymore.
And nobody really likes to be told how to do their job, so it’s better to be operating at a higher level and helping the engineering team move on prioritization and making sure they understand the vision, the why and the how – sorry, the what and the why. But the way they can help the team is by asking the right questions. So, it’s fine to ask, “Hey, I remember this part of the stack was built this way.
[0:54:00]
Could we have this – in the shorter term, could we do X, Y, and Z shortcut if needed, because we really, really need to try and learn and test but then come back and fix this?” as opposed to just saying, “Why don’t you just go and do this? I know this part of the code. This is how it should be done.” There’s a nuance there. So, I think that’s very true of early product managers who move from engineering to product.
And then, also, if you are still stuck in engineering trying to go all the way deep into the implementation, you only have X hours in a week to work. So, how are you helping the team with the other stuff that we talked about earlier, about understanding the customer, the analytics, prioritization, cross-teamwork? All of that stuff is being dropped probably. You’re not spending as much time on it because you’re still stuck in part of the code and trying to figure out how to best implement this.
Bryan Reinero: Yeah, that’s a good point. It might be easier for those of us who come from engineering to kind of flavor our product management style with – too heavily with engineering-focused stuff and neglect the interaction with customers, finding customers, facilitating their conversations with the engineering team.
[0:55:00]
That can go undone.
Harsh Sinha: Yes. And in general, engineers and technologists in general tend to be more solutions-focused – so, given a problem we tend to gravitate towards a solution. And the whole premise of product management is to continue to go down the rabbit hole of why and what more than how. And if you stick to the how more, then you’re basically not doing a helpful service to your team.
Bryan Reinero: So, how should a product manager judge or measure the success of themselves? How should the team – what expectations of the – should the team have of the product manager?
Harsh Sinha: So, I think – the way I think about this is for most good teams, teams rise and fall or succeed or fail together. But some – when I see great product managers, if you’re the product owner, they tend to take the victories where it’s a team effort and they tend to take the blame a little bit on themselves on like… you know?
[0:56:00]
And not just because they should be the fall guy but more around being the leader on the team and being able to articulate and do retros and be able to point as to what could have been done differently, as opposed to expecting the team to just figure that out themselves.
And I think that’s very, very important. If you look at really good product leaders, they tend to have this thing in common where the success is – always goes to the team executing well and understanding the problem that they’re solving and shipping something that is really loved by the users. Around the success criteria, I think if you take that into consideration, if you have – the team is learning faster. And if the team is being able to iterate and get more feedback from the customers and improve the product than if they did not have the product manager in the team, that is a very, very big sign that the product manager is being successful.
[0:57:00]
So, how do you get to learnings as quickly as possible and actionable learnings as quickly as possible is another way that I think product teams value and measure the success of a product manager.
Now, of course, not – one person doesn’t make the team, so of course the team has to be willing to go through that process of actionable learnings and iteration. But given all the different elements of building a product, in a product team you usually have designers who look at making user flows very nice and beautiful and useable and making it a rich user experience. You have got engineers who think about architecting a really scalable, extendable system. And you’ve got customer support folks who have got – who are providing great service. You’ve got all these different functions, and the product manager kind of is the bridge or the glue between all these functions. And they tend to be the person who is carrying the vision and making sure that the entire machine is running and keeping the main goal in mind of which metrics they’re moving, –
[0:58:00]
how they’re moving it, and making sure the team is focused and not getting too narrowly bogged down in their own domains.
So, if eventually the team gets to the point where they’ve having those actionable learnings and really moving customer metrics, then a lot of the credit does go back to the product manager implicitly within the team because the product manager is helping the team succeed.
Bryan Reinero: And one final question, a parting thought: What would you say is the single most important aspect of product management as a discipline?
Harsh Sinha: Wow. I think it is about enabling the team – inspiring the team, enabling the team to learn and iterate fast, and then getting out of the way.
Bryan Reinero: Yeah, that’s nice. It sounds of course that the success of a product manager is not necessarily the right perspective, but perhaps that what is going to be successful is going to have the team be successful. The team becomes more enabled, more empowered, more efficient, more capable.
[0:59:00]
Harsh Sinha: Exactly. So, exactly. The success of the product manager, like any leader at any other company or organization is if the team is successful, then they’re successful. Hence, when I say inspire – maybe inspire, define, bring the customer voice, help the team iterate and learn. And as they go along the process, as they become this self-learning machine and they can do this stuff by themselves, you can get out of the way and go on to do something else and inspire another team and inspire – and solve another problem.
Bryan Reinero: Well, thank you very much for joining us, Harsh. I really appreciate your time and your input.
Harsh Sinha: Thank you for having me, Bryan. It was great.
Bryan Reinero: This is Bryan Reinero for Software Engineering Radio.
Voice over: Thanks for listening to SE-Radio, an educational program brought to you by IEEE Software Magazine. For more about the podcast, including other episodes, visit our website at SE-Radio.net.
[0:60:00]
To provide feedback you can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our Slack channel at SEradio.slack.com. You can also e-mail us at Team at SE-Radio.net. This and all other episodes of SE-Radio is licensed under Creative Comments license 2.5. Thanks for listening.
[End of Audio]
