The Product Management Leaders Podcast
The Product Management Leaders Podcast
Build vs. Buy Decisions, Managing Stakeholder Relationships, & Breaking Rules (with Nariman Noursalehi, SVP of Product @ tZero, Overstock)
Hi all, we are excited to share the sixth episode of The Product Management Leaders Podcast with you!
Our aim with this podcast is to connect you with some of the top PM leaders and share their real-world strategies and tactics for building world-class products.
In today's episode, Grant Duncan speaks with Nariman Noursalehi, the SVP of Product Management at tZero, a leader in blockchain technology for capital markets, and was previously a VP at Overstock. He has a wide variety of experience ranging from being a PM, marketer, and even has a law degree from UVA.
Leave us your thoughts about the episode and subscribe to be notified of the upcoming ones!
This podcast is sponsored by Voximplant, the leading serverless communications platform and no-code drag and drop contact center solution.
Voximplant enables product leaders and developers to integrate communications into their products such as embedding voice, video, SMS, in-app chat, and natural language processing and it enables customer service teams to run their whole operation from one place.
Join over 30,000 businesses trusting Voximplant such as Burger King, 8x8, and Hyundai.
If you have any questions, tweet Grant at twitter.com/grantmduncan
Grant Duncan 0:05
This is the Product Management Leaders Podcast in which you hear from some of the top PM leaders about their real world strategies and tactics for building world class products. It's sponsored by Voximplant, the leading serverless communications platform and no code drag and drop contact center solution. Voximplant enables product leaders and developers to integrate communications into their products, such as embedding voice, video, SMS, in app chat and natural language processing. Join over 30,000 businesses trusting Voximplant. Now let's jump into the show.
Hey it’s Grant Duncan, your host. Our guest today is Nariman Noursalehi, the SVP of Product Management at tZero, a leader in blockchain technology for capital markets, and was previously a VP at Overstock. He has a wide variety of experience ranging from being a PM, marketer, and even has a law degree from UVA. Let’s get into the discussion!
So to start us off, can you share a little bit about your role and what the company does? And I hope I got your name right!
Nariman Noursalehi 1:27
Yeah, no, that's perfect. So I work for tZero Group, I guess is our technical, like legal name, but everyone just calls us tZero. My role there is I'm a Senior Vice President of Product Development. I'm one of two VPs on the product side there, which I guess is the focus of this podcast. So what tZero does, we are a blockchain company, our initial focus was entirely on securities trading on the blockchain. So most people, I think, even a lot of the regulators, have said that the future of you know, securities trading is going to be on the blockchain, it brings some unique benefits to that in particular, like right now, if you're on any, any broker, and you buy an Apple stock, let's say, it takes a couple days for the trade to actually settle. And it's because different parties have to do different roles. And the unique thing that blockchain can bring to that is, even though different parties have to do different roles, with smart contract tech, they could all do that at the same time. So one of the early kind of slogans of our company, is that the trade is the settlement. So the trade and the settlement happen at the same time. For most people, you know, that type of dekay is kind of meaningless, but but really, it does cause a lot of problems in the financial system. I mean, part of what happened with GameStop, like the GameStop fiasco, where the price, you know...
Grant Duncan 3:00
Yeah, I was thinking about meme stocks when you're talking!
Nariman Noursalehi 3:03
Yeah, so that like where it just spiked and the value of GameStop went from what, like $20 to $350, overnight almost. And then Robin Hood, which was one of the biggest platforms that was trading at the time had to turn off trading. The main reason for that is actually the delay in the settlement, which is kind of weird, so banks will essentially assume that you're going to cover the cost, but it takes two days for it to actually happen. So you end up borrowing. All the action that happens within those two days, and they just couldn't afford to pay for it. So they had to turn off trading. So that's the problem we're trying to solve. Our goal, I mean, if you look at our products, it looks a little different than what I described. We have really two parts to our business. There's the tZero Markets, which is our registered broker dealer. That's where you can go right now and buy... we have three digital securities that are trading - Overstocks OSTKO, which was paid out as a dividend, our own coin, which is called TCROP, and then we have Aspen Digital, which is actually a Ritz Carlton in Colorado. We have a lot more that are coming this year, but it's a fully licensed US broker dealer. And then on the other side, we have tZero Crypto is what it's called, which is more what I think the late person would think of a crypto business. It's, you know, it's a platform you can get on and buy and sell cryptocurrencies, Bitcoin, you know, Litecoin, Ether, all those things. And the goal from the product perspective, which I mean bringing it back to product, is that we have two different and distinct entities that we have to bring together, which normally would be pretty easy, but with the regulations around it, it's a little more complicated. Yeah. One is markets, regulated by FINRA, and tZero Crypto is regulated by banking laws, federal and state banking laws. So just bringing those together, it's a little, a little harder than it should be, I would say.
Grant Duncan 5:10
Wow, yeah, I imagine that adds a lot of complexity to your product decisions. So, with tZero being in the blockchain and crypto space, you know, that's, I imagine something maybe difficult to explain. How do you talk about what you do to family or non-tech people? When they ask, you know, what do you do for a living?
Nariman Noursalehi 5:36
I actually love that question! It's one of the challenges, I think. So my history is, I think, a little unique for a product person, I actually have a law degree, and I was a practicing lawyer for years before I switched over to the tech side. And so when I talk to my family, in particular, my mom and my dad, I mean, they're like, why aren't you being a lawyer? Yeah. And I have to try to explain what the hell I'm trying to do with my life. But really, with blockchain, I mean, it's never worthwhile to get into the weeds of how it works. And I actually think this is a good perspective to take from a product, like when you're defining requirements, especially is, think about it from what the user could get out of it. And, like, how do you explain to your mom, what the intrinsic value of Bitcoin is? Or what, you know, how do you explain to your mom, what a blockchain backed security is, and how tZero can really help improve the world really, and I mean, the best way I can ever describe it to them is to talk about the problems that exist in those systems. So the monetary system for cryptocurrencies, or the securities markets, Wall Street, what are the problems with Wall Street in general? And then say, you know, our company is trying to use technology to solve that, and you don't really have to go much further than that. But, you know, if I talk about it not from the perspective of a problem, or what we're trying to solve oriented, it never makes sense then. But everyone understands that there's issues on Wall Street, everyone understands that there's issues with monetary policy. So there, that's the problem. We think this technology can solve it.
Grant Duncan 7:28
Yeah, that makes a lot of sense. So can you share a little bit more about tZero and your team? How many people are in your team? And how do you have it structured?
Nariman Noursalehi 7:39
So you know, it changes a lot, we actually have a very fluid company, which I think is a good practice, because it gives you more flexibility and much bigger ability to shift as priorities change. So we alternate what engineers work on. But, I mean, if you get down to it, right now, I have three engineering teams. So one that's entirely focused on tZero Crypto, so trading of cryptocurrencies. And then two of the teams that are focused on the markets and securities trading side. And again, like I said, a little bit earlier, there's two BPs, you know, that report to the Chief Product at tZero. He manages quite a few teams, about the same number as well. With the the nature of this business, and we've been around for a few years, tZero's a little more than five years old. So we're not exactly like early stage startup, but we still act like a startup. So you end up wearing a lot of hats. I also manage, let's see, I have three dev teams, I have two full time product managers. I also have a customer service team, the people who actually answer the phone report up through me right now, which doesn't seem intuitive, but that's our best connection to our customer and the pain points. So we decided to put it under product rather than keeping it under the traditional business side. That's on the crypto side. On the broker dealer side, it's against the law for them to report to me, because they have to be licensed and I would have to be licensed too. And then in a previous life, I was a marketing executive. So I also have the marketing team report to me, which you know, right now, it's a humble team. If we had marketing at scale, then there's no way I could handle all that. But right now, I have a really great manager under me. So it's pretty hands off. It's just a little advice here and there.
Grant Duncan 9:54
Wow! Yeah, that's a that's a lot of people to manage, and think about even you know how to create a culture among all those people. I'm particularly interested about having customer support report under you as that's not as common. Can you share a little bit more about what those interactions for the customer support team look like with the product and engineers?
Nariman Noursalehi 10:20
Yeah, it actually works out a lot better than I thought it would. So again, I mean, it all comes down to having strong leaders under you. If I had to do day to day management on it, I wouldn't get anything done, ever. But we have a strong director under me that manages the day to day customer support issues. But the value of it is it really closes the feedback loop. I think, you know, a lot of product people... And this is like, one of the mantras that you'll hear everyone say is, you know, you do what's best for the customer, you have to interact with your customer. And they do these focus groups, or they do demos, they try A/B testing, but the biggest improvement... And I've done all that, and I'm not saying it's value-less, you know, it's very valuable, but day to day, knowing what are people complaining about? I think some of the best enhancements we've made, have been because of that - a direct result. I mean we've never had a customer call in and say, Hey, you need to add this, you need to integrate with this company, because they're going to provide a more seamless onboarding experience. It's not like those kinds of bigger projects, but it's these like little tiny tweaks that you can make that really makes a difference. And for me, those are some of the things that are the greatest things you can do as a product manager, or in a product or something that takes minimal dev effort, but has maximum impact for the user, which is great.
Grant Duncan 12:02
Yeah, yeah, those are great examples, kind of reminds me of just trying to find those quick wins. When you started at tZero, were there any big Aha moments? Or learnings you didn't expect or quick wins you were able to find to add value in the beginning?
Nariman Noursalehi 12:24
I would say yes. So tZero, because it's in a highly regulated industry, kind of had two big phases. One was, you know, really building the heavily regulated parts. And I was kind of introduced when they were already started and building out the customer more low level investor facing parts. So in addition to all of the investor facing products I've discussed, anyone who has a security that wants to trade it can come to us, we'll create a representation of it on the blockchain and habit trading essentially the next day. So that's the side of the business that was being built out initially. I came in after they'd already started building out the more UX centered and investor facing products. And that's where I think I've had a lot of the big impacts. And another thing, tZero, I mean, our senior executives are primarily product focused and have experience there, which used to not be true. So I came in at a time where we could make that transition. And the entire company realized it's a build phase, we quickly expanded the number of engineers. And there was a lot of, you know, chaos in it. But, oddly, I think like some of the wins I'm most proud of, I mean, there's the big ones, like we launched the app, or successfully actually bought a company and we had to convert their app to our app, and get the technologies. Those were huge challenges and huge accomplishments to succeed. But the things I'm always happiest with, again, they tend to be much smaller, like, you do this little thing that you're just proud of. An example I can think of is we have our back office support, and they have to deal with day to day issues. And honestly, I kind of went rogue and decided we really need a tool for them. And, you know, we're building all these really neat, sexy sounding products. And I'm like, I want to build an internal app so they can update a customer's phone number without having to do a database deploy, something like that, where, you know, I kind of hit it under the radar. It wasn't a huge project. I mean, if it was big, I of course, would have to justify it to everyone. But built it and since it went live, you know, we keep adding more and more to that same app. And now, it's a core part of our business. And, you know, I think those are the things that I'm always happiest with. And the only benefit we really... Like if you distill down like, what did that actually do? Did nothing for the customer, but it saves our engineers from having to do manual product support or production support, it saves them from having to get emails daily from a customer service agent, and just all the distraction. So it just made us more efficient, I think. And those are the things I'm always happiest with. But I really can't attribute the change in culture to myself, it really... I came in at the time when the culture changed.
Grant Duncan 15:45
Yeah. Yeah, it makes sense. Well, I'm sure you helped contribute to it. You mentioned that you all acquired a company and integrated the app in. How do you think about the build versus buy decisions? Maybe at tZero or in the past? Because I think, you know, a lot of PM leaders have to think about similar kinds of decisions.
Nariman Noursalehi 16:08
That is an exceptional question. And I wish I had the super straightforward answer that could resolve it for everyone. But it's always going to be a challenge. And I mean, the first thing I look at when I'm making those decisions, it's a cost benefit analysis, how much time do you save by buying at what costs? You know? And when I think about that, it's not like if I built it myself, it's six months and a dev team cost a million dollars a year. So that would cost 500k? It's not like that. If we go with the buy option, a year from now, how much further along in our product roadmap would we be? How much value do we get out of saving ourselves this much data and focusing on other things that are valuable, that have to happen? Or this has to happen before that can? That's the way I start to look at it. But then there's always the, you know, everyone... Not everyone, I shouldn't speak in complete hyperbole. But, you know, most vendors that you talk to, when you talk about like how difficult is the integration? Oh, two lines of JavaScript? I don't know. Like, I thought it was like a joke that they all said the exact same thing. But a lot of people do think it's just two lines of JavaScript and you're integrated. And a lot of times you find that...
Grant Duncan 17:34
Live in production, too, right?
Nariman Noursalehi 17:36
Yeah. Oh, of course, of course, no need for testing. But, I mean, I've heard that so many times and been burned by that. But, you know, I always assume it'll be a lot more than some front end writes two lines of JavaScript and suddenly you have a new, you know, Q&A section on your product page. That's not realistic. But it's trying to dig into that, like, what is really the complexity of integration. And what's the real complexity of integration to get full value. A lot of times, you'll see a product that is amazing, has hundreds of features, and you talk about integration, but you realize you get a quarter of the things that you thought you would get. You can get them all, but you just have to put more time into it. Yeah, I've been burned by that many a time, I've decided to buy versus build and regret it. So it's a tough one. And kind of the last thing is just how much control do you want of that part of your business? Like how custom do you want, whatever it is... like for our CS platform, we bought, you know, I'm not going to build a customer service platform from scratch. There's a million companies out there that do it, I don't need to have a high-high level of control, you know, people have figured out how to do it effectively and... Just buy it. In other areas, from a previous job, not at tZero, but the Q&A section on a product page. We decided to buy and realized that was not the best choice.
Grant Duncan 19:13
Yeah, that makes sense. That's good insights. Thanks. So how do you go about the planning process? Whether it's annual, quarterly, monthly?
Nariman Noursalehi 19:25
I love this question. To be honest, if you kind of look at my evolution as a product manager, we'll say. Not as an executive, but just as a product manager. And everyone claims they're agile, you know, I've realized that word is completely meaningless. I've never seen a product manager resume that doesn't say agile, and I've seen a billion different implementations of agile, so kind of...
Grant Duncan 20:00
That's a good hot take!
Nariman Noursalehi 20:01
Yeah, haha! And I think to some people agile is like minimal planning, let's just start executing, and then we'll learn as we go. And for other people, they're planning-heavy and the other agile PM, will be like, Oh, that's waterfall that's not agile. And, you know, they're both wrong and they're both right. I started off more on the former, I just wanted to build, start building, go as quickly as possible. Very little planning. Like, I know, I want this, let's just figure out how to do it. And as we go, we'll write out more and more requirements. The further along I've come, I've realized more and more what the value of planning is. And, I mean, it's a good and timely question, I think, because I'm about to launch an internal test on a new way to plan a project. And we've tweaked it, we've tried so many different things at tZero, but the new one that I'm going with... I realized one of the biggest disruptors to our productivity and deploying at the dates we give, you know, we're gonna try to deliver by this day, and then you slip... everyone's slips, it's no big deal. But what are we doing wrong beforehand? And the one of the big gaps we always had is communicating up, up as in like, to the all the way up to the CEO, what exactly we were planning to deliver. And what we wanted to do as fast follows and what were going to be future enhancements. `really those three areas, right, those are the things that we always knew as product, we tried to cut scope. And again, you know, trying to be agile, deliver as quickly as possible and enhance it, or trying to be like lean startup style, same, same exact discussion. But you know, I can't explain how many times I've had a product that is so close to launch, and the executive actually sees it for the first time like end to end, and wait, why is it this feature? And they're like, Oh, we agree, we're gonna deploy that three weeks later. And they're like, No, absolutely not has to be there before. I mean, it just completely derails everything, it feels like. So that's part of it, the in scope, out of scope, and out of scope is defined as fast follows versus future enhancements. Future enhancements are the things that's no big deal. Fast follows is, the dev team won't be working on a different project, because they're going to continue to work on the same product, you know, so that's half of it. And then the other half, which I don't know if it's unique to our heavily regulated business, but I think it's really compounded by the heavy regulation of the business. And that is, for us, compliance tells us we have to do something, or that we can't do something that we're planning to do. It's a nightmare. Honestly, like, imagine building an onboarding experience for a retail company, you want them to have a sign in with you. What do you ask for? Email, password, right? That's it. That's onboarding. For us, we have to actually do KYC, which stands for know your customer, but it's a federal requirement. And we have to verify their identity. So you have to get a driver's license, you have to, you know, do all of these checks. And it's just painful, painful, how much it disrupts a good user experience. I mean, it's a good idea. If they didn't have it, there'd be a lot of fraud and whatnot, but just managing that, we've gotten burned by that before too, where, you know, legal and compliance team sees the design after dev has been underway for a while and they're like, Oh, no, you can't do that. And, you know, you wasted a sprint of dev work on something that's not allowed. So that's part of the goal of this document, is we just have like a questions and executive summary just like lay person speak of what we need. And so that way, legal, before the designs, before anything, could see what we're planning on doing and shut us down if need be.
There's a few more sections. So it's not that interesting, but essentially, for me planning before was, you know, writing a detailed requirements document, making sure all the stakeholders were happy. But I realized that I always said I was doing that, but mostly I just wrote requirements, you know, like one of our stakeholders is compliance, I would just tell him like, Hey, we're gonna build this, I wouldn't actually go into the minutiae of it. And if I give them the requirements document, but to them, probably... One of my old bosses used to always say it was a dolphin speak, like, he could understand what the engineers were saying, as much as he could understand the dolphin sometimes, because you get really technical in there. So I think there's some value, well, I'll test this, it might not be true. So talk to me in a couple months, I'll tell you if it worked or not, we're literally like, doing it this week, we're doing our first project on this model. But I think that's the side of planning I never did before, which was having a summary that any idiot can read and understand exactly what you're doing. And you can get sign off from people. Not like they sign off on the requirements document, which before they did, but again, they didn't understand it. But planning is hard. It really is hard.
Grant Duncan 26:10
Yeah, I think that's an interesting way to break it down. I imagine some of our listeners might try to incorporate your test and see if it works for them.
Nariman Noursalehi 26:23
This might be an executive, you know, Product Management, type philosophy, but really, the most important resource is our engineering bandwidth or throughput. And the more planning you do, the more you can make sure that that throughput is focused on the right things and are adding value to the company. And as far as what a ground level PM should do, is everything and anything they can to make sure their engineers don't get distracted from writing code. If your dev lead is creating the JIRA tickets that represent your user stories, or whatever model you use, that's a waste of time. They're in there just typing your words out in a different, you know, platform. That's a waste of time. Yeah, the engineers should be writing code. I think it makes them happier. And it makes your company more productive. But it ends up with the PM having to do a lot of busy work, but it's worthwhile in the long run.
Grant Duncan 27:29
Yeah, that makes sense. Since I live in the San Francisco Bay Area, I obviously have a lot of friends that are engineers, and a lot of them do talk about just wanting to code and not wanting to be in meetings, like I just don't enjoy them so much.
Nariman Noursalehi 27:46
Yeah, I just want to code! That's one of the things I think COVID has really made worse is the number of meetings, not having everyone together, you know, where you can just go ask a question. And I'm probably one of the most annoying people for an engineer to work with, because I just screw around and go distract them all the time. They even jokingly got these red buttons that would glow. And if they press the button, like dammit, you're not allowed to ask us any questions. If the red button is on we're working! But, I mean, given that it has its downsides, but like, if I had a simple question, I could just ask someone. You try to do that on Slack, you try to do it on email. But having like, a five minute conversation is the equivalent of an hour and a half on slack. It feels like. And then even though, you know, email and slack are a great tool... I mean, I can't imagine working without something that's the equivalent of both of those at least, great tools, but it's that task switching that I think has a high cost. I could be in the zone working on a presentation, let's say I'm an executive, so I don't do anything meaningful anymore. So I'm in PowerPoint, doing super important work, but you know, I get a slack message and I shift over, I look at that and when I go back to the presentation, there's at least five minutes to actually get back into the flow thing. So this one second message actually costs five minutes, which, I mean, it sounds like I'm you know, being draconian about it, but you get 100 of those a day that's 500 minutes, that's more than a day. It compounds and gets bad really quick. And then with the meeting dilemma, which all by engineers have said the same thing, I hate it. I hate going to meetings, I hate wasting my time. I just want to code. I just want to code. Now instead of just walking up to someone and asking them a question - you schedule a 30 minute meeting. You bullshit for five minutes and then you start to get into the substance. And it's just bad. So we do, as a practice, just meeting grooming, just start getting rid of reoccurring meetings, which ones don't add value, which ones should be bi weekly, which ones should never happen, who's on this meeting that really doesn't need to be there. And then the other thing... I tell it to all of my direct reports, at least, is unless you know that you have to have to be there, the meeting is about something that you're directly related to, no one will ever care that you missed a meeting. When was the last time someone calls in sick and they're not at the meeting, and you're like, Oh, my gosh, we can't have this meeting anymore, because this one of the 20 people isn't there. So I encourage people just to decline meetings, especially recurring ones, if it's important, of course attend, but if it's just that meeting where you update everyone? That's a waste of time.
Grant Duncan 30:58
Yeah, I've been doing something similar and thinking like, okay, who really needs to be at some meetings, and try to cut it down. Because that's a great point.
Nariman Noursalehi 31:12
Yeah, it really gets out of control very quickly. Everyone schedules reoccurring meetings, and no one ever cancels reoccurring meetings. At some point, there's gonna be a problem.
Grant Duncan 31:24
Yeah, totally. So when you think about your teams, what are some of the core metrics that you are tracking?
Nariman Noursalehi 31:33
That's a good one. So really, we do two things. I probably should have mentioned this in the planning section before, but we we use the OKR models. Oh my god, I can't remember what OKR stands for...
Grant Duncan 31:51
Objectives and key results. We use it to.
Nariman Noursalehi 31:56
There we go! Frozen on the spot. So, of course, that's one of our metrics that we measure the teams by and, you know, it's pretty cascading. I think we do a relatively good job about it, the CEO or the company OKRS, I take a slice of that, and then the people under me take a slice of that, along with some things that maybe are outside of it, but it's mostly working towards the same objective. So one of the things we measure, and we actually don't use it as a performance review at all, I think that's a waste of OKRs, honestly, if you're doing that. Because everyone will just sandbag and give the easiest things that they could possibly deliver. But we're more interested in... I've had quarters where I get like an 85% score at the end. We grade it on zero to 100, how did you accomplish your key results. And I get these really high scores, and I'm like, Oh, that's horrible. I messed something up in that quarter, I wasn't aggressive enough, I wasn't thinking big enough. And then I honestly had a quarter where I got like, 11%, and that was like, Oh, I completely overshot the market. I mean, in that quarter, you know, something external that we weren't aware of came in and just ate up all of our time. So we didn't get to work on any of the things we planned. But both of those just mean that the the way that we think we're working is different from the way we want to work. So, so then when you get down to like, measuring your teams, it shouldn't be on the grade they get there, but how can you ensure that you're being, both, as aggressive as possible, trying to deliver as much as possible, while maintaining quality of life? Maybe the best way to get as much done as possible is everyone works 14 hours a day, glued to a computer, you know, but I think, going back, it has to do with planning, and one of the things that we require with projects is how are you measuring the success of the product after it goes live? Of course, analytics is the most basic thing in the world. And then the second half is, how are you measuring, you know, throughput, and the actual development of that product. I used to be very data-centric on the end results, which I still am, you'll never get away from that. But now, the throughput side of it, I realize is a lot more important. It's amazing how much time and effort is wasted on stupid things that don't add value, that just eat up time. So how do you measure that people are being as efficient as possible? And I think the only way to do that is to have retrospectives and keep that as part of your sprint planning and retrospectives, because they're intangible numbers. I'm not going to look at like, how many hours was this employee logged in? Because that's creepy.
Grant Duncan 35:07
Yeah, those are good overall ideas, though. Can you share about how you manage stakeholder relationships? You know, a PM has to work with so many different groups. And even as you're mentioning, you have the compliance addition to it.
Nariman Noursalehi 35:26
Yeah, that's hard, especially in big organizations. It gets really tricky. We've spent a lot of time like doing complete ground up reorganizations of the entire company, to try to deal with exactly that issue. So, I mean, that's why customer service reports to me, as I mentioned earlier, it's because they were a stakeholder, they were getting ignored by product. They were reporting up through compliance, I think. So they were just this orphan child. And they would identify issues that no one would address because it just never bubbled up correctly. So I mentioned earlier that we're doing this executive summary document. That's what what I'm calling it, super creative, haha. I think that's a good start. I love, you know, tools like Google Docs, I've learned this weird lesson, maybe like six months ago. I would email someone to get an answer, and I wouldn't get it. I would get a fake fuzzy answer, a let's schedule a meeting type answer. I tried all these approaches outside of a slack messages, and it wouldn't work. And this is on stakeholders. In our org, you know, we use our tools that we use them well. Or, like I said earlier, we'd show them the requirements and say, are we missing anything? But it would be a link to a Confluence page. And I think just because it was Confluence, their head would blow up and they couldn't process it. So we started literally copying and pasting it into a Google Doc. And then you hit the little plus button and at, you know, at compliance, Is this okay? And you would get a response, like, instantaneously! I don't know why, I don't know what the psychology of it is, I don't say to know. But that's been a very effective tool. You know, you always want them to be informed of what you're doing and understand what the benefits and what their responsibilities will be in the world afterwards. But it's how do you effectively communicate that without wasting a lot of time, you know, we used to do these, like project kickoff meetings, and there would be 100 people that would be invited, and someone would put together this great deck, and they'd go through it like, we're going to move this button up by three pixelsб , this is what we think we're gonna get. And I mean, it ended up just being busy work. And this is before COVID, people would be in the meeting, just screwing around on their laptop, completely not paying attention. So the goal was to work with your stakeholders. But that was never the end result. But for some reason I've had success with, you know, we still do a summary like, this is what we're going to do. What are the risks? Here's what you guys need to do type, you know, discussion, meeting, maybe 30 minutes. But for some reason, just putting it in a Google Doc, and then commenting it to them - it literally has saved me so much time. And again, I tell you, I'm in a compliance heavy area... This is literally one of the conversations that it took me maybe three days to get an answer to that, I think in my new doing the comment in Google Docs, it would have taken me 10 minutes. It was: do we need to collect middle initial? That's it! One field, and I want as few fields as possible in onboarding, right... I don't have a middle name. So maybe I'm biased. But do we need to collect the middle initial, like, how important is that, in onboarding? You know, for me, as a product person, less is better, easier is better. But for compliance, you know, it's a whole different story, but trying to like, pull that information out of them is painful. I don't know what it is.
Grant Duncan 39:29
Yeah, that's cool to think about testing other forms of communication, to engage each group in a way that, you know, makes sense for them. And I'm sure when you think about the information needed to collect for you previously working at Overstock, you have that ecommerce mindset that, you know, you don't need a lot. I'm sure it's a change.
Nariman Noursalehi 39:58
Yeah, yeah, exactly! I mean, it's just good practice, I think, in my space specifically, not Myspace, the former app, but my work area...
Grant Duncan 40:10
You mean you don't still use your your Myspace?
Nariman Noursalehi 40:12
Oh, I do. You've got to see the picture I have, the music that plays automatically, you'll love it! Haha! I actually want to... I'm curious what's there now. But Robin Hood is an amazing company. And the thing that they did, it disrupted. I mean, it's an app, onboarding on an app is like the biggest nightmare in the world. Onboarding to a broker dealer on the app is a nightmare too, but things that had become assumed to be absolute requirements by compliance people in the broker dealer space, they didn't do. And they never got in trouble for it. And they were always successful in KYC-ing. So that's the argument I make with them more often than not, is, well, these guys don't collect it, how do they get away with it? And, you know, they realized that... The old strategy was collect as much as you can, because there's zero risk, you know, the new world is you got to eat some risk. And then the other thing is they would keep, you know, like traditional compliance people, they would just keep adding additional things to the onboarding and never remove anything. But technology advanced far enough, where... I mean, the end goal is to identify the customer. Now you can do it with email history. Is that the same human being that logs in on Amazon as Nariman with that email that logs in on your app with that same email? So the technology advanced to make ID-ing a customer a lot more efficient, but the number of things they asked didn't get more efficient. So it's like these things that are just kind of hard coded, and, you know, to use the cheesy Silicon Valley, the TV show term, "We got to disrupt that!" But I mean, that's really what they did. Anytime anyone has been doing the same thing for a long time - you should question it.
Grant Duncan 42:07
Yeah, yeah, that's a good quote there.
Nariman Noursalehi 42:09
Yeah. Here's a really stupid story. But I think it's super valuable. There was an analytics team at a company I worked at, that every week would get together this spreadsheet and send it out to all the stakeholders. Every week, this person would go and write the SQL script and send it to everyone. It would take a person two full days to get it together, it would come out on Tuesday, and they'd start on it on Monday. And someone's like, "Wait, why do you do that?" And they're like, "Well, that's what we do, we send them this data". And someone, in their spare time, wrote a script that would automate it. And then that person never again have to spend those two days pulling that together. He would just download the CSV at the beginning of the week and send it out on Monday. And that's something that that team had done for 10 years. And one person, who's like, "Why do we do it that way?", changed everything! Internal disruption.
Grant Duncan 43:09
Yeah, that's amazing. Scripting can be very helpful for internal processes as well. It's a great example. Are there any other like t product management strategies that you'd want our listeners to hear before we wrap up?
Nariman Noursalehi 43:25
I think the biggest lesson I would have to product people, and I'm thinking of like, what do I do in my one-on-ones with product managers over the years and, and there's a couple things that I think make effective product managers and actually make effective employees. Number one is that they own their product, even if they don't care, you could be working on the most banal and like boring, just horrible thing ever. But if you own it, own it. If someone tells you to do something that's different from your priority list, you know, defend your priorities against it. I don't know how many times someone has come over the top, you know, over the top, like an executive sense, "Work on this instead of this". And then later, if you regret it, you're like, why didn't I do what I originally had planned, because you're the most familiar. So fight for what you believe in. And then the second half of it, which kind of goes along with that, I think it does go hand in hand with ownership, is every now and then just break the rules, go rogue, do your own thing, try something completely crazy. Sometimes you can't, you know, tell your boss, that you're doing it, that stupid little thing... Every now and then it's worthwhile to just go rogue. Everyone tells the product manager, act like you're the CEO of your own business. You know, this is your domain. You don't get to act that way realistically, in a company, but every now and then you should. People will tell you to act like you're the owner, but then they won't let you act like the owner. So every now and then just do your own thing. Don't tell anyone, your dev team will love it, by the way, because usually it's something that they've wanted to do forever. And they have gotten the chance to. And just say, look, act like it's tech debt, spend, you know, 20% of your time working on this project... We'll be doing the bulk that they told us to do, but let's do this too! Just like, go rogue. I mean, that's what made my career is doing something I shouldn't have been doing. But it proved to be valuable. And that's how I showed my value. And if you think you're right about something and you have good reasons to think you're right, and no one will let you do it - break the rules, screw it. If it doesn't work out, worst thing that happens is you find another job, which there's plenty of right now.
Grant Duncan 45:54
Yeah, good take!
Nariman Noursalehi 45:55
Yeah. I think that's it from me.
Grant Duncan 45:57
Yeah. Cool. And if you could think of one other person that we should have on this podcast, who comes to mind that's another PM leader?
Nariman Noursalehi 46:08
I knew you were gonna ask us and I came up with nothing good, by the way, as an answer to it. There's a gentleman named Michael Lovelady, I can help you connect to him. He is crazy, like no other way to describe him. He's equally brilliant and horrible. But he is one of the smartest and most product centered people I know. He would be worthwhile. I think he just consults now.
Grant Duncan 46:38
Okay, Michael, we'd love to have you on! If you're listening. Thanks so much for your time today, Nariman, great talking to you!
Nariman Noursalehi 46:44
Thanks, guys. Bye!
Grant Duncan 46:49
Thanks for listening to today's podcast, and thanks to our sponsor, Voximplant, as well. If you're looking into how to improve your communication and customer engagement, check them out. Lastly, if you enjoyed this episode, please leave us a review and tell your friends, so that others can find it more easily. Have a great day. And feel free to reach out to me, Grant Duncan, if you have any questions you want asked in our next episode.