Podcast: Play in new window | Download

Joe: [00:00:00] OK. So Sean, next episode, here we are. And today we’re going to be speaking with Rohini Pandhi and she’s a product manager at Square, and I met Rohini, we met back at the industry conference in Cleveland in September and we were sitting at a roundtable and Rohini started talking about different ways that, at Square, she manages her team’s road map and how they prioritize. And I found it very interesting and asked her if she’d join us today. So Rohini, hello.

Rohini: [00:00:27] Hello, thank you for having me on.

Joe: [00:00:29] So just to get us going, would you mind introducing yourself giving us some of your background, your role, how you got to be where you are today?

Rohini: [00:00:37] Sure. Sure. So I started off as a computer engineer who decided after graduation to not be in front of a computer programming anymore and so I went in to kind of like a technical consulting role after school. And I did that for a few years, became a road warrior, kind of got to have an expense account and travel around the country which was pretty fun. After that, I realized that I could either continue on that technical route or try something different. So I went back to school and did grad school to get my MBA and then realized there was a nice, cool, new role called Product Management that was the intersection between my technical and business sides. So I just kind of stumbled upon product as a career and fell in love with it. I worked at a lot of startups on the West Coast and then went to Square just a few years ago. And I work on the Square invoices product line for the company.

Sean: [00:01:36] Very cool. A quick question for you, so where did you go to get your MBA?

Rohini: [00:01:40] I went to the University of Chicago. So on the south side.

Sean: [00:01:44] Awesome.

Rohini: [00:01:44] Yeah.

Sean: [00:01:45] I went to the Simon School, University of Rochester….

Rohini: [00:01:48] Cool.

Sean: [00:01:49] …to get my MBA, and I’m curious to know what you think about that in the context of product development. Do you think the MBA was helpful? And if so, how do you think it was helpful?

Rohini: [00:01:59] Sure. I get a lot of questions from people who ask if they should be getting their MBA. And I think that’s such a, it’s a case by case question. It’s an expensive education, for sure. For me, it was really worthwhile because it helped me to break down the engineering mindset I had and think about things and solving problems in a different way. And so a lot of the frameworks I still use day-to-day. The frameworks that I learned in school I still use in our strategic planning or our competitive landscape comparisons and things like that. And so I think it’s a great way to get hands on experience, but it’s not for everyone.

Sean: [00:02:37] Oh, I agree and it can be a very expensive proposition.

Rohini: [00:02:40] Exactly.

Sean: [00:02:42] But how do you say no to anybody who’s looking for more education, right.

Rohini: [00:02:44] Yeah. I always say that if I won the lottery, I would just go back to school. I would just learn as much as I could on different topics. That would be so much fun.

Sean: [00:02:54] For me, I think that there’s a lot of quant tools in the MBA program, at least at the Simon School. So there’s a lot of statistical tools that I think were valuable, and that whole sort of approach to business was valuable.

Rohini: [00:03:07] Yeah. We had a great program that was more on the experiential learning at Chicago. And so you built your own business or you did competitions on something that you built yourself, and it just kind of demystified a bit of what entrepreneurship meant for me. And I think that entrepreneurial side is really important as you kind of take on product, especially early stage products.

Sean: [00:03:30] I couldn’t agree more with that. I do think having a little bit of knowledge around the language of business and accounting all those sorts of things can’t do anything but help you build better products. And to know how the business is thinking, like to know that at the end of the day, we always have to tie our success back to an ROI of some sort and profit.

Rohini: [00:03:50] Right, yes, it was great. I mean, I think, kind of like what you were saying, Sean, it was the first time for me to even see a balance sheet or an income statement. That was like the first time I’ve ever even looked at those things. And so to be able to speak that language now was incredibly helpful.

Sean: [00:04:06] Cool, so let’s jump into the meat.

Joe: [00:04:07] Yes. So today’s episode is really, you know, we’ve had some episodes around like vision and you know, how to think about products at a high level. Today is really about getting in the weeds. It’s very tactical, you know, what do we do with roadmaps? Just to start off with that, I think, you know, a lot of companies they define roadmap in a different way. So just for you guys, how do you differentiate between what a roadmap is and then a release plan or a project plan?

Rohini: [00:04:34] Yeah. I kind of think of all of these artifacts as different levels of detail, kind of sitting and zooming out. So for us at Square, or at least on our team, on invoices, we have the highest level, which is kind of our strategic plans, that include like the vision, the one- to three-year horizon outlook of what we’re going to go accomplish, our competitive and market landscapes and things like that, our customers jobs to be done at a high level. And so we have that plan. It almost looks like a business plan, but it’s our strategic view of where we want to take this product over the next few years. And then a level deeper we have our quarterly, it could also be multi-quarter, goals. We use OKR’s as the way to kind of outline that level of detail. And then we have our actual roadmap and that includes all of our projects that are in flight or in the backlog. So the roadmap would have line items for each workstrain that’s going on right now and then link out to even more details like our eng or jira tickets, our launch plans, things like that, that offer even more detail if want to get into the weeds. But most of our cross-functional team kind of looks at things at that roadmap level and when we expect timelines and milestones to be hit.

Joe: [00:05:57] Very cool, so at the company level they’re setting the vision strategically for the product. That’s a bird’s eye view, and then you get further and further down and you’re getting more and more specific. That’s how you’re looking at that.

Rohini: [00:06:07] Exactly. And really when you say company level, that is actually our team, our product team. We’re the ones making those goals and aims for everyone.

Joe: [00:06:16] Got it.

Rohini: [00:06:17] It really helps kind of tie the team and make sure that we’re all held accountable for the things that we’ve just said we are going to go accomplish. It’s not like some consultant that came in and said here’s what you should do for your business. You kind of are very attached to the goals that you set for yourself. And so it’s intentional and it’s by design to do it that way.

Joe: [00:06:35] Yeah, I mean so you’re essentially getting a bunch of autonomy and then you’re also accountable, though, at the end of the day.

Rohini: [00:06:40] Exactly. Exactly.

Joe: [00:06:41] So a lot of different roadmaps are out there in the world, you know, even companies like Facebook and whatnot, they put a roadmap out for the public to see. But like you were saying, it’s very very high level. How do you structure your roadmaps? Do you have timeframes on them? Is it certain chunks. Like how do you actually structure yours?

Rohini: [00:06:59] Yeah, I’ve seen a few different styles and I think everyone should kind of use the style that works for their company and their culture. I believe I even have a actual like Photoshop version of ours with some details cut out in a recent blog post that I put out on road mapping. So if anyone’s interested, it’s on Medium. You can just search for me and you’ll hopefully see it. But we use just a simple Gantt chart that we’ve built in Google Sheets, and it does have timelines by week. So I don’t get granular into the day because that seems too precise, but we do need week-by-week because we have a lot of cross-functional partners that rely on these release plans and large dates so that they can coordinate things from the marketing communications, when engineering starts rolling things out we want to put our support articles together, and so we want everyone who’s either an account manager or anyone who’s customer-facing, like account management or support or whoever else, to be able to see that and say, “oh this is why somebody has reached out to me because they’ve started seeing this feature that’s been released.”

Sean: [00:08:02] That’s great. You mentioned OKR’s in your first answer. So objectives key results, kind of like a KPI, key performance indicator, of some sort.

Rohini: [00:08:10] Right.

Sean: [00:08:11] So I like the fact that you’re tying that, and you also mentioned jobs to be done, which we’re big Clayton Christensen fans here as well.

Rohini: [00:08:18] Cool, yeah.

Sean: [00:08:18] So you tie the jobs to be done, and your OKR’s, I assume, are associated with your getting those jobs done for your customers. So I’d like to just pull on that OKR thing a little bit. So give me some examples of what you’re using, what you’re measuring, to know that you’re getting these things done.

Rohini: [00:08:34] Yeah. I mean, I’ll be completely transparent with you guys. I think that we aren’t doing the best job at our OKR level. I’m going to put together a proposal, in fact, like this week, to change our process for 2019 kind of going forward. Because we have a few things, that like you said, are evergreen. They are key jobs that our customers hire us for and we should continue driving those and making sure that we have the right kind of engagement and retention at those levels. But then there are certain amounts of risk taking that we should also be comfortable with. And I don’t want our OKR’s to get too stagnant and us getting complacent. So I also want to put in some objectives that are not just aggressive but something new that we haven’t really dug into and making sure that those are still accounted for and part and parcel of what we go do per quarter. Just allowing us a little bit more bandwidth to make those extra bets.

Sean: [00:09:28] Well I didn’t want to derail us too much from the roadmap conversation, but you mentioned that, so I wanted to pull on that for a little.

Rohini: [00:09:33] Yeah, hopefully I’ll have a better answer for you in terms of our process next year.

Sean: [00:09:38] No, I like where you’re heading. That’s really neat.

Joe: [00:09:40] Just to set up the next couple questions, do you use the concept of epics in your roadmaps?

Rohini: [00:09:45] So we use a little bit of both. So we have the Google Sheets, which has the high-level projects. And then within Jira, in our ticketing system, we have epics, and so each epic kind of lines up to a work stream in our Google Sheets roadmap. And so we just pretty much pull these things from our backlog in order to put them into the roadmap and then we break those down into individual tickets from an epic into Jira.

Joe: [00:10:09] Got it. And then do you size the epic somehow as a first step once it gets in there?

Rohini: [00:10:15] Yeah. We look at a few different things. We work in six week cycles just to break the quarter up a little bit more in order to have a bit of a tighter turning radius. And one of those weeks is pretty much set just for planning and our engineering planning. And so we look at the scope of work, we break it down into bigger tickets, and then we do a level of effort estimation that is really led by engineering to be able to help us say, “OK this piece is going to take this amount of time or this number of sizing,” and then we do that for all of the projects that are in there to say, “OK this can actually most likely get done within six weeks, or, “this is really a twelve week project that needs to be either rescoped or reprioritized.”.

Joe: [00:10:58] Just to keep digging here for the listeners… So t-shirt sizes? Do you use that, or how do you actually put a number or size on those?

Rohini: [00:11:05] So we actually first start off with t-shirt sizing and then we go into more details. So we use t-shirt sizing for our backlog and that includes a level of effort estimation. The other pieces of our backlog in terms of a priority framework, we use Adam Nash’s model which he kind of has a great blog article, again for anyone that’s interested it’s called the three buckets of prioritization. I’ve used that in the past and we use it in the invoices team as well where we look at customer feedback as one of the buckets, metrics movers as a second bucket, and then what I usually refer to as foundational work is the third bucket. So it’s something that may not move a metric right away. No one’s asking for it just yet, but in order to get to where you want to be in two to three years you need to have this foundational or visionary work kind of completed. And so those are the three buckets. We added an extra one called level of effort. And so what we do is we prioritize against those three buckets and then we also look at the prioritization by level of effort. And we use t-shirt sizing for all of that. Again, because we’re all analytical nerds, we like to have, instead of small medium large, we go from extra small, which is a one, to extra large, which is a five. We put it in a spreadsheet and we actually start scoring things and having an average kind of pop out of that scoring system.

Sean: [00:12:25] Great. That sounds like, then you’re keeping some sort of measures too around the size of your backlog so you can control the flow of the requirements.

Rohini: [00:12:32] Exactly. Exactly. And so there’s always going to have to be a tradeoff. When you say something’s actually going to go into the que for building and so we look at it by that score a level of effort and how impactful it’ll be. And then we make a decision based on that.

Sean: [00:12:48] OK. So your impact measures are sort of, what bucket is in? Is it foundational, is it metric mover, is it? OK.

Rohini: [00:12:53] Exactly.

Sean: [00:12:54] Interesting.

Rohini: [00:12:54] Yeah.

Sean: [00:12:55] So we have this concept at I TX called the minimum viable backlog.

Rohini: [00:12:59] OK.

Sean: [00:13:00] We know we need to keep the backlog at least this full to keep the team flow super healthy, right.

Rohini: [00:13:06] Yeah. Gotcha.

Sean: [00:13:07] And then we have an optimal backlog, and then we’ve got our long-term backlog, which in theory should continue to grow forever, right. If we have great products, we know that there’s always something you could refactor, something you can improve, or…

Rohini: [00:13:17] I like that. That’s cool.

Sean: [00:13:18] Thank you. Do you guys measure the size of your backlog? Is that a factor?

Rohini: [00:13:23] We don’t, and the way that we’ve gotten around measuring our backlog is that our six week cycles are planned for well ahead of time. And so we know, kind of in that six weeks, how many folks we have that are going to be kind of working on backend server stuff, front end, mobile, we kind of know our capacity planning at that point, and then we say, “OK here are the big boulders that we want to put into the six weeks and here are maybe the rock-level improvements that we want to see,” everything else that’s kind of like pebbles and so forth are moved into individual sprints or are kind of cherry-picked by the engineers themselves because they either find something frustrating or they want to improve some specific part of their code base that they own. And so we tend to not put too many pebbles into the planning and if there are a bunch of, I’m going to keep going with this analogy, but if there are a bunch of pebbles, we’ll actually start grouping them into themes of work and making them about a rock size.

Rohini: [00:14:22] Interesting. That’s neat. Do you guys measure the quality of the backlog in any way, and if you do, what tools do you use for that?

Rohini: [00:14:28] What do you mean by the quality of the backlog?

Sean: [00:14:30] So, how much rework has to get done based upon the poor requirements, for example, or…

Rohini: [00:14:36] Oh, I see, I see.

Sean: [00:14:38] …defective user stories versus actual, you know, not in terms of software bugs. In the nature of software development, sometimes the user stories themselves can be defective.

Rohini: [00:14:46] True, true. Yes.

Sean: [00:14:48] Do you have any sort of a measurement system for that?

Rohini: [00:14:50] We don’t measure it in an analytical way, but what we do is when we go through our backlogs, we have folks from the design leads, the engineering leads, and the product leads all sitting in a room together on a regular basis. Every two weeks we actually go through the backlog, and we put anybody who has actually inputted an idea or has heard an idea from other cross-functional partners has to put their name behind this piece in the backlog that’s either the user story, use case, or whatever the definition of that project is. And so if we all sit in a room and we’re like, “what is this?” and that owner of whoever inputted it into the backlog cannot describe it in a full way, then that person has to go back to the drawing board and say, “in order to submit something like this I need to know all of these other requirements.” It doesn’t mean that a full user story at that point needs to be spec’ed out, but we have to understand what the problem at hand is. And so if we don’t understand the problem or we disagree on the problem it’s probably going to get a low score anyways. And in order for someone to champion it, they really have to be quite clear about what that backlog meaning is.

Sean: [00:16:00] Makes sense.

Joe: [00:16:01] So kind of along that line, with the model, do you see that certain requests that fit into one of the three buckets tend to win out more? Like do the customer requests supersede any of the other kind of requests?

Rohini: [00:16:13] Yeah, so actually go into even more detail on our model, what we do is we say that the customer requests could be a couple different things. So they could be things that we’re hearing from the support team, and so that would be like a, I guess a sub-bullet inside the customer bucket, or it could be things that we’re hearing from our community forum. And so both of these could be really important inputs for us. Either, like, our support threads are just getting way out of hand and the support team can’t manage everything, so for that quarter, for instance, let’s say our support requests are highest priority, we just need to decrease those. Then we’ll put that as a higher weight into the average that’s being calculated because we really want to push that metric down for the quarter. And a lot of this goes back again to the OKR’s, everything kind of feeds in and out of itself of what we’re trying to accomplish. Similarly with metrics movement, maybe our risk loss is like really important for us that quarter and so we will prioritize and make sure that we call out, “would it have any material impact on risk loss?” If not, it’ll get a lower score with all else being equal. Like, we’ve waited risk as being a big deal for us that quarter and so we’ll actually put weights around things. You kind of see the outcome as based on what weights you’ve all agreed to for either the quarter, or the year, or however you want to arrange it and collaborate with your own team. But it’s never like customer success will always win or the customer bucket will always win because you’ve already weighted it. Unless you weighted it where it’s like 90 percent customer bucket and 10 percent for everything else, that part should already be determined before you kind of go into this operational process.

Joe: [00:17:52] Got it. Got it. Makes sense. See you mentioned a meeting where it’s like the engineering leads, design leads, product leads. So just to kind of piggyback that, ballpark how many people work at Square or how many teams do you have now?

Rohini: [00:18:04] Oh, we have, I think we’re close to 3000 employees worldwide. But the invoices team is a lot smaller than that. I’m not sure if I’m allowed to say, I don’t know.

Joe: [00:18:14] No, that’s okay. So my question is basically, we look at a lot of big companies or enterprises or as companies grow they have to adjust with that to keep their teams aligned with what the vision is for the product and keeping them motivated and aware. So a typical kind of meeting or ceremony you hear them start to adopt is like a scrum of scrums. So my question is like, how do you all stay tied together with what you’re all each working on because I’m sure there’s times when the problems you’re solving or the requirements are going to kind of intersect and you have to work together or look out for that.

Rohini: [00:18:44] Yeah I think we do kind of use a scrum of scrums idea. So on the roadmap, we have a call out for the folks that are responsible from: there’s one person responsible from the engineering, design, and product side of the house. Sometimes we have more responsible parties on the engineering side because you need someone for each platform, like web mobile and server. But we have someone that’s kind of like supposed to be on top of every project from each discipline. And so those project teams tend to get together more frequently to either have stand up or sprint planning in and of themselves. And then we also have across all projects that are happening for this product planning weeks and retros in the classical sprint-style meetings for everyone. But usually it’s only the direct responsible parties that are speaking on behalf of the entire team because otherwise they would just get too long of meeting, too many updates, there’d be just so much going on. But we try to kind of create these smaller teams that then feed into the larger one, and then even within our product teams we then report out so that other product teams kind of know what’s happening, and then our VP’s C-level, C-suite folks can also see and connect the dots at their level.

Joe: [00:20:03] Very interesting. Can you speak a little bit more to that planning week and what that looks like and then the output of how you report out just in general what you have going on.

Rohini: [00:20:13] Yeah absolutely. So that planning week, it’s really focused for engineering. It’s just focused time where they’re not trying to build but also plan. And so it creates a little bit of a break in between our cycles where we say, “OK for this week you know the work that’s going to be happening, we all kind of understand what the customer problem is, we understand why we need to be doing it and why it’s a priority at this moment.” And then at that point, the product piece has been defined, or the business case has been defined, and then design has usually by that point also done several versions of exploratory work and have some mocks that are pretty close to complete. And all of that has already been work that’s been done with engineering involved. So even from the definition phase to the exploratory phase, engineering has always been involved, so that we can make sure that the stuff that we are talking about isn’t completely out of left field. But then at the point when there is a planning week, that means eng has a lot of the definitions and now we need to go into, “OK, what’s going to happen week over week, and what do we know versus what do we not know how to do just yet?” And so any work could be really just it’s a simple document where we just say, “OK, here’s the work, here’s what we need to get to, what are the things that we need to build in order to get to that point?” And the discussion is led by the engineering lead with inputs from the entire team. We rotate who the lead is, and we say, “OK, for this project, so and so is really interested in being the lead, so therefore they’re really just the point person that I can go to with any questions, that design can go to with any questions, and everyone just reporting status and updates to them.” And so they will go through and say, “OK for server work, here the end points we need to make sure we have, for the mobile team, when can we expect an Android version versus an iOS version?” And then they break down that problem into even more granular details, and week over week here’s what we should expect. If something isn’t a green light in a particular week that means it’s going to be moving into that next week. And then I can look at their breakdown document and say, “in week three, oh crap we’re really behind because everything’s red instead of green.” And I can either go into the Jira tickets to learn more about what just happened, or I can go talk to that engineer lead and say, “OK what are some of the tradeoffs, where can we either cut out requirements, change the scope, or what do we need to do to change the timeline?”.

Joe: [00:22:33] Awesome.

Rohini: [00:22:33] That was a really long answer to your question but I hope it covered everything.

Joe: [00:22:37] I think it’s great information because people are doing their work day to day all the time and they sometimes don’t get to hear other perspectives of how other companies work whether they’re in Silicon Valley or not. So it’s really good to just hear about how the day to day happens, like how does this software actually get made. It’s really not magic. There’s no special sauce. It’s just grinding through and prioritizing and making sure that you’re on top of everything.

Rohini: [00:22:59] Yeah and I think what we’ve learned is, like you said there’s no special sauce in this, and a lot of it is just operational processes that either will work for us or won’t. And then we’ll throw them out if they don’t and we’ll try something else. We try not to get too heavy-handed on the process, but communication, it’s an n-squared problem, right, with n being the number of people you have on the team.

Sean: [00:23:19] Of course.

Rohini: [00:23:20] It’s just exponential and we need to make sure that we’re all kind of aligned. And so this works for us, but I love talking to other product folks on what’s worked for them in the past and what hasn’t, just to keep our processes as lean as possible but also affording the structure with some of the benefits of creativity within that structure.

Sean: [00:23:40] Yeah I have an opinion around that. So process itself, it’s a word that generally means restrictive, right. Like you have to follow this process. Actually in software, if we’ve learned nothing else over the last few decades, it’s that we need to give teams a certain degree of flexibility to produce the best possible products. We know that. So it’s better if we frame what we would normally call a process as a best practice.

Rohini: [00:24:02] Love that.

Sean: [00:24:02] These are the best practices as we know them today, that doesn’t mean we’re not open to changing them, but this is what’s helped us provide predictable results over the years. These are the best practices that we know, but we should always be open to adjusting them and experimenting with those just like we do with the features of our software products, right.

Rohini: [00:24:20] Yeah, I love that. I think the words, matter language matters, and so just even changing the framework. Like even when you said that, in my mind, it just changed how I thought about the ways that we do our process and then just changing it to best practices means rules that are allowed to be broken and they should be if something changes.

Sean: [00:24:37] Right, it doesn’t mean you shouldn’t be accountable for that. I mean if you’re going to make a change to a best practice, you should have a good reason and it should be treated as an experiment.

Rohini: [00:24:44] Yes. Yeah that’s very cool. All right.

Sean: [00:24:47] Next question we have for you is around motivation, and the product that you’re building is an invoicing product.

Rohini: [00:24:54] It is.

Sean: [00:24:54] It’s not so sexy, no offense. So how do you get the team motivated to produce the best possible product?

Rohini: [00:25:03] You know, I guess I’m pretty fortunate in that the team that I work with is very passionate about this. I think that it doesn’t come with a certain degree of a product mindset in all of the disciplines. And what I mean by that is like, having some user empathy or customer empathy around what we do. So for the folks that are already pretty jazzed about you know providing payments in an invoicing format, I love bringing them along in customer interviews, in onsite visits, that kind of stuff; because it just puts a face or a story to the problem. And it still affects me even now after having done however many thousands of hours of interviews over the years. Just when I talk to someone and they are kind of holding back tears on a phone call where they tell me that we offered them capital financing from Square at the very moment that they weren’t able to continue their business, and because of our financing, it extended their cash flow for another 30 or 60 days when their invoice was getting paid. And that was just like awe-inspiring to see how many small businesses and customers we have who just rely on this type of suite of products that all of Square has in order to make a living, but then also achieve a lot of the professional dreams and goals that they even set for themselves where they’re starting something on their own or they’re trying to build something for their community. And it’s just a really fun aspect to be a part of that story with them.

Joe: [00:26:33] I think that’s so important, what you just mentioned about telling stories to your team because the first thing someone might think when they hear invoicing is, “oh, you’re just sending receipts,” but really you’re allowing them to conduct business and conduct it well and it’s taking something that’s typically a nightmare of a process and making it easy. And that’s so important to give your teams, and this is for all of the product managers out there, newer to it or been doing it awhile. Don’t forget to do that. Do it regularly, like they should be hearing and seeing all that. Like you said, take them along with you sometimes. That’s amazing.

Sean: [00:27:06] That was the best answer ever.

Sean: [00:27:11] Hahah, oh good.

Sean: [00:27:11] And it supports this ongoing theory that I have and that we push here, in that any compelling vision has got to connect the people that are achieving the vision to the people that we’re solving problems for. You hit the nail on the head and I think taking your people to meet with real customers and making sure that they really understand the problems that they’re solving for other people, that’s what underlies all motivation. There’s a lot of science to prove that, and we talk about that stuff a lot on the podcast, but you just hit the nail on the head.

Rohini: [00:27:40] Yeah it’s eye opening. I mean for all of us, too. I still love those customer conversations to this day. It’s kind of the best thing about being a product manager is having those on a regular basis. And then also having the team realize after two or three conversations that there are definite patterns that already start emerging of, “oh this would be something cool to do” versus, “we absolutely need these types of things.” And for us, the thing that I constantly hear is about faster payments and your cash flow piece, right. It’s, “if I don’t get this money like immediately or yesterday, I don’t have enough to fund the next project that I want to go do, and if I don’t have that…” Cash flow just becomes this recurring nightmare for our sellers, and so kind of realizing that we’re not just an invoicing product but the payments piece is so crucial. And how we look at payments, it’s not just if it is a pretty looking invoice, but all of the key pieces right underneath that. I think Square it does a really good job of being a little bit like an iceberg where you still see the top piece of that iceberg and it’s very simple and clean it to the point and the designs are really well done. I think our product engineering and product design team are just incredible at what they do because they take all that complexity that lies underneath the water and just hide that from a lot of our customers that don’t need to know, how does a payment actually happen? And it hides a lot of the financing tools that we need in order to be able to offer this type of loans to our customers. And so the ability to take something really complex and messy and tough to handle and make that really beautiful, simple, elegant, and remarkable at the end is a lot of work. And if you can highlight to your team why that piece is so important, why hiding it is very important, why people care about the key pieces of your value props and how to make those even better, that becomes your differentiator and your source of lifelong customers.

Sean: [00:29:25] Again you hit the nail on the head. Just a little side note, I’ve been a Square customer since the beginning of time.

Rohini: [00:29:32] Oh no way. OK, cool.

Sean: [00:29:32] So I’ve got a little side hustle. I started buying and selling antique jewelry as a very young guy at like 16 years old. The first credit card I took was from Square and I’ve been a huge fan ever since. I was such a big fan that in my little local antique community I got a ton of people to sign up very early on.

Rohini: [00:29:51] So cool.

Sean: [00:29:51] And again, I’ve always believed that Square has found success because of their focus on the user experience and putting their customers first. You guys certainly have lived that set of values.

Rohini: [00:30:02] Oh that’s great. I’m so happy to hear that. That’s fantastic. The product side of me wants to hear all of your feedback now but we don’t have time for all of that on this podcast, but at some point I will be reaching out to hear what’s good, what’s bad, what’s working, what’s not.

Sean: [00:30:16] To be honest it’s a side hustle and I don’t do it a whole lot anymore. If I do set up at shows, it’s only for charities, it’s for nonprofits and I bring my kids along.

Rohini: [00:30:25] Oh cool.

Sean: [00:30:26] When my son was literally 5 years old he could process a credit card and take payment for a ring. So…

Rohini: [00:30:33] That’s great. That’s awesome. We should have him on some of the commercials.

Sean: [00:30:39] He’s 18 now, so…

Rohini: [00:30:41] Oh, OK.

Joe: [00:30:43] All right, so we’re talking about tying your teams to your customers a lot. So I have to ask, do you use user personas in any way, shape, or form. And if so, how deep do you go using them, meaning, you know, some people use them in their road maps to prioritize, all the way down to obviously as a persona name in their stories.

Rohini: [00:31:03] We don’t use the traditional sense of customer personas because we are, as a company, kind of focused on jobs to be done and so we have jobs-based language that kind of breaks things down into more detail. We don’t say like, “twenty-five percent of our roadmap needs to fit this job,” but it’s more of either how important or how impactful is it on kind of our three buckets checklist based on all of the different criteria that we have listed out. But we will say, like, “the reason that we’re doing Project X is because it helps our customers accomplish this, and the customers that need this hire Square in order to do X Y and Z.” And so we do use a lot of the jobs language. We also use, I sometimes do deep dives into week-long interviews of just hiring jobs or just our firing jobs. The reasons that people choose Square invoices, the reason people leave Square invoices, and really understanding, “what kind of buckets are there of different jobs that we satisfy or we fail at for our customers?” And so we reorganize things. It’s not just bottoms up of, “here are all the tickets, here’s the backlog, here’s the roadmap.” It’s also looking at things and challenging ourselves from top down, saying, “OK, what’s out there in the competitive landscape, what jobs do we satisfy versus a PayPal or a Quickbooks? What jobs do those tools satisfy and why would you choose one versus the other?” And really understanding that core need. And then also the acquisition piece. It’s both for product and it also definitely helps product marketing.

Joe: [00:32:42] Yeah a lot of the roadmaps that we’re trying to push now don’t include features, they include problems to solve.

Rohini: [00:32:47] Yes. Yeah. So that’s what we’re tending to get drawn towards and move towards.

Joe: [00:32:51] So you mentioned the iceberg example before, and we use that analogy a lot here too. So I’m curious, when you’re working on any kind of a product at Square, how do you factor in the non-functional requirements, the NFR’s, such as security, performance, tech debt, compliance? How do you build those into your roadmap and backlog ultimately?

Rohini: [00:33:14] Those usually go into our PRD’s, our product requirements documents, to make sure that things are kind of at least accounted for or unknown to our teams that care about the security and compliance pieces. So we will actually kind of outline for our legal, or compliance, or our risk team, “hey, we’re gonna go do this work, we’re going to build it in this way.” That’s kind of a known pattern around Square, and we want to just make sure that their eyes are on it so that they know that this is happening. If they have any issues with the design or how we’re going to go build it, it’s known way before the project gets kicked off. But we don’t necessarily have a roadmap item that says, “make sure all of the tech debt that we’ve accumulated for all of compliance is done by this date,” unless there’s some sort of like, new GDPR-type of law that’s in place and there is an actual date. We try to build all of that into each product work stream that we work on. We don’t want any holes in our security with any new feature, we don’t want any legal issues with features that don’t get accounted for for six months, or something like that. So we try to put those part-and-parcel with the work that we do.

Sean: [00:34:26] That makes perfect sense. Those are non-negotiables.

Rohini: [00:34:28] Exactly.

Sean: [00:34:29] Last question. We ask all of our guests. What is one book that you found powerful enough that you recommended to your team or to other people in this industry?

Rohini: [00:34:39] So OK. The one that I really like and I’ve gotten as a gift. It’s a really small, short book but it’s so fantastic. It’s called Steal Like An Artist, Austin Kleon, K L E O N, it’s just a great way to remember how to break some rules and kind of get out of the box thinking, like we were talking about, how process can help, but then also, you know, breaking some of the paradigms and working like an artist in the things that you do day-to-day. Again, it’s very short, very small, it’s actually a small, physically small book, but I really enjoy it, It’s just fun to read and I often find myself kind of going back to it and trying to remember some of the quotes that he puts in the book just to kind of push my own thinking. I mean it’s not really like a product or business book so I am also starting to read Principles by Ray Dalio and just finished up Sapiens by Yuval Noah Harari. Both of those are just like wonderful, so far on Principles, just a great framework that Ray kind of puts together in his past background, but they’re both like 700 page books and I love reading real books. I don’t have a Kindle version.

Sean: [00:35:54] I’m the same way.

Rohini: [00:35:54] I know. There’s something really nice about the tactile version of reading.

Sean: [00:35:58] And I just read a statistic, every form of media is on rapid decline, right, from obviously music and video all that stuff is dying, it’s like everything’s being streamed but books are still expected to continue to grow at 1 to 2 percent forever into the future and they’re still pretty solid.

Rohini: [00:36:16] Oh, I love it. Yeah. I really enjoy having an actual, like that’s the first hardware that I’ve had. So it’s just really nice to have a book. But I will warn the listeners here, those are like really big ones. And I have accidentally fallen asleep with one and had to wake up because it was hurting, I was on my chest and stopping my breathing. So maybe get the Kindle version or the audio version, but they’re both fantastic books.

Sean: [00:36:43] Cool. Well I definitely like the first one that you mentioned, the idea of stealing from artists. I think it was, what was that guy’s name? Bernard of Chartres, I think. “We are all standing on the shoulders of giants,” right. All of our discoveries, there’s really nothing new, we’re putting things together in new combinations, but we’re all standing on the shoulders of giants.

Rohini: [00:37:03] Exactly, yes. And it’s really about that. There’s very few and rare true innovations. It’s about how do you reapply some known things. One of my professors from my MBA once said, “well stolen is half done,” and I still use that to this day. It’s so true. Well stolen is half done.

Joe: [00:37:23] That’s a good one.

Sean: [00:37:26] Awesome.

Joe: [00:37:27] Well, Rohini thank you for joining us today. It was amazing to hear and get a glimpse into how Square works and how you specifically work with your team and manage roadmaps, and backlogs, and motivation. So thank you so much.

Rohini: [00:37:39] Thank you both very much. I appreciate it.

Sean: [00:37:42] Super impressed. Very good interview, thank you so much for your time, and taking time out of your day to join us for this.

Joe: [00:37:46] So you mentioned Medium. Where else people find you if they want to connect?

Rohini: [00:37:51] I’m also on Twitter. It’s @RohiniP. And I’m sure, I’m on Linkedin, I’m the only Rohini that’s at Square. So you should be able to find me.

Sean: [00:38:01] Outstanding.

Joe: [00:38:02] Alrighty, well thank you again so much.

Rohini: [00:38:04] Awesome, thank you.

Joe: [00:38:06] All right. We’ll talk to you later.

Rohini: [00:38:07] OK.