How One Street Artist Became Head Of Product At Atlassian

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Hannah Clark: It takes a lot of guts to change directions in your career, especially if the path you're looking for doesn't really look like the one you came from. According to NovoResume, 43% of career fencesitters are reluctant to transition into a STEM field because they feel they don't have the right industry related qualifications. So, if you've been thinking of moving into product management from a less "technical" field, or you're a hiring manager working with these kinds of applicants, you'll find this conversation fascinating. 

I spoke to Natalia Baryshnikova, GM & Head of Enterprise Agility at Atlassian. Natalia spoke to her own atypical career path and how it's helped her weave principles from the art world into her work—first as a product manager, and now as a leader. She also had some excellent advice for evaluating fit for product team and leadership roles. But my favorite part of the conversation is at the very end, when she shares the most important reason why becoming a PM was the best career decision she ever made. Let's jump in. 

I am so pleased and honored that you were able to join us today, Natalia. Thank you so much. 

Natalia Baryshnikova: Likewise, thank you for having me. 

Hannah Clark: So you have had a very unconventional career trajectory, and I'm wondering if you can tell us a little bit about that background?

Natalia Baryshnikova: Yeah, absolutely. Like you said, today I'm a general manager of a business unit, but I started my career in product as an individual contributor.

And then a lot of PMs, I think aspire to eventually grow into a general manager role. So that's what my PM career look like. However, my career started a long time ago and my first paying job was actually being a street artist on the streets of Moscow a long time ago, so that's how I made my first money and that helped me pay for my college degree. And then I had some stints in the big law, so I used to work for big law firm early on, and that definitely shaped how I think about product management. 

One thing I learned in big law is attention to detail, which is a very helpful skill in product management. But then my journey brought me to business school and I went to business school at MIT, which meant that you cannot go for MIT and not become obsessed with technology. So that's what happened to me. And even though I originally did not plan to be more into technology as I got to take classes at MIT Media Lab, I just, had to give in and got enchanted with what technology can do and what's possible with in particular startups and thinking about things from the first principles.

So that eventually led me to asking the consulting company who I had an offer from to wait a little bit and let me go and play a little bit with startups. So after business school and after I graduated, I showed up in the Bay Area in San Francisco, because that's where the startups were. And I was meeting with founders and early employees of startups.

And I would say, Hey here I am, I would like to work for a startup. What do you think I can do for you? And I kid you not, I had a spreadsheet where I tracked about 400 meetings. And eventually the pattern started getting very clear. People were telling me like, Hey, you have a good eye for detail and you have a good taste and you can think about things in a structured manner, you should be a product manager.

And one of my former managers used to say, "When you ask for money, all you get is advice, but when you ask for advice, sometimes you get money." And so what eventually happened, one of the venture capitalists that I met with liked me enough to introduce me to one of his portfolio companies that was going through Y Combinator at the time, and they needed a product manager, and I don't know how that happened.

This is luck component of my journey, but they hired me, and so that was an ecommerce and travel startup, and that's how I landed my first product management gig. So I spent a little bit of time in consumer product management, specifically in travel and ecommerce spaces. And then eventually I transitioned into enterprise software product management.

First, I spent a good amount of time in people technology space. And then I joined Atlassian about three years ago, where first I was on the confluence team. And so then I joined the enterprise agility team, which is a set of tools by Atlassian, like Jira line that helps organizations connect strategy to execution.

And I run that business right now. So I actually work with product management leaders who report to me. So I'm now quite removed from figuring out which features they would build because I trust my team to do this, but that journey would not be possible without all those little bits and pieces that I went through.

Hannah Clark: Yeah, that's interesting. And it's such a full circle moment too, just now working on software that product managers use as well. So really fascinating stuff. Coming back to sort of those early days in the product management space, how did you find that, were you surprised at all by how elements of your background influenced your approach to product management?

Natalia Baryshnikova: Oh, I totally was. And one of my earliest realizations was that if we think about software and particularly how humans interact with software, there are a lot more parallels between, for example, like what Leonardo da Vinci wrote about and what you see on a computer screen today than people think. Because humans have not evolved that much since, da Vinci times.

We still have two eyes, mostly. We still kind of interact with things in the same way and the same methods. And so the core principles of human computer interaction are very similar to the principles of how do we consume art that da Vinci wrote about. Ironically, I never thought that would be true, but my background in that art education was actually extremely helpful because a lot of the constructs in software.

Because it's made for humans, at least these days, maybe it will be made for non-humans soon. But for humans today, it is made for the same humans that da Vinci was making his art for. And there's a lot to learn in there. 

Hannah Clark: That's really interesting. Are you able to give an example of some of the art principles that you found to be very parallel between software and art?

Natalia Baryshnikova: Yeah, absolutely. One of my favorite constructs from art that I use almost every day is the concept of negative space. And negative space is a concept that basically when you paint a picture, you sometimes paint explicitly, which is like you add color to things that you want to look in a certain way, but you can also send a message by painting around something and leaving it empty.

So for example, you can leave a shape and people can guess what that shape represents. And the reason it is very relevant to product management is we often say that product managers need to tell a story. We need to create a narrative and the negative space is a perfect concept for that because you tell a narrative not only by explicitly saying something. 

But if you want to, for example, portray a gap in your strategy, if you're talking about product strategy, or if you think about user journeys and you want to capture a product opportunity that right now is not served, then portraying that negative space, something that is not filled, but there are things around it, is actually very similar conceptually to the concept of negative space in art. And that's something that I often teach my PMs to think about negative space when they think about storytelling and crafting narratives for product strategy, for example.

Hannah Clark: That is so fascinating. And I would have never drawn that parallel either. Have you heard of any other sort of stories from PMs that you've worked with that draw sort of an interesting parallel between a background that they've had and what they do today that you would have never thought would be relevant?

Natalia Baryshnikova: Yeah, that's a great question. One of my favorite interview questions when I interview PMs is actually teach me something about anything in the next two minutes. Presume that I don't know anything and just talk to me about something that you're fascinated by and there are no wrong answers. And the answers that I hear to that question, they come from all sorts of backgrounds.

And I've learned so much about how to calm down a crying toddler, the principles of nuclear physics or how to basically manage a submarine. So I think that to me, I often say that product management is about being able to abstract things. And I am a firm believer that all experiences that we go through as humans can be abstracted to a certain set of principles and patterns that are very useful.

And so I really love to learn from others, regardless of their backgrounds, because I feel like everybody has that something and whether you're a nuclear physicist or whether you're from a sailor, whether you come from a human psychology background, there's always something that's very relevant.

It's just that by comparing the problem spaces and talking about them that you oftentimes figure out what is similar. But you know, patterns are fundamentally overlapping across so many different trajectories and so many different spaces. But in general, I really like to learn, and I encourage my team always to learn from things that may not be related to software, because I think there's such a big world outside of it that it's great to learn from other spaces too. And I definitely do it myself, not just from art, but from other things. 

Hannah Clark: Yeah, absolutely. And I think that always adds a certain element of diversity when people are coming from different backgrounds and think about things in different ways. It makes for interesting end results. 

So coming at things from a hiring perspective, when we're talking about people who might be outside of the space and are considering and trained to product management, what are some of the markers that you see when you are evaluating someone's background, regardless of whether it's, traditionally technical or not, whether that candidate might be a good fit, or if someone might see themselves as a good fit?

Natalia Baryshnikova: Yeah, that's a great question. And that's a question I get quite often so thank you for asking it. You use the word technical. So I wanted to walk you through my framework for how I believe in product managers and then challenge that term technical a little bit, or rather dive into what we mean by technical.

So when I interview product managers, I usually think about what I call a HACK methodology. And it's an acronym. Who doesn't like acronyms, especially amongst the product managers, especially the ones that sound kind of technical. But H stands for humility, because as product managers, you have to work with a wide variety of stakeholders.

You work with people who are smarter than you, you work with people who are experts in areas that you know absolutely nothing about. And so without humility and just not just human humility, but also intellectual humility. And knowing that you can be wrong, you can make an assumption and it'd be erroneous and there's nothing wrong with that. 

And the ability to kind of move on from that with the team and have the team go with you, I think it's impossible without humility. So I always look for that intellectual humility and personal humility. And the best product managers that I've had the privilege to work with, they definitely possess that quality.

A in HACK acronym stands for analytical, which is my version of saying technical. The reason that I say that I feel like oftentimes we over index on saying, Oh, does this person know how to code? But what you really need as a product manager is actually to be able to think in systems and to be able to use good old formal logic that I particularly learned in my legal times.

And I'm talking about like plutonium logic, like that sort of like N3T level logic to various spaces, because that's how you figure out things that you don't know. And even though there's a high overlap between technical backgrounds and possessing those skill sets, it's really that skillset that you're after.

And so having excellence in logic and thinking and systems does not necessarily have to come from technical background. And when we say technical, we often mean software engineering or anything of that nature. However, if you are a mechanical engineer, you're not even called software engineers technical.

Or like if you're a nuclear physicist, one of my PMs is from that background. They're like, yeah, I don't know if software engineers are technical. So I think that I usually try to dig a little deeper under the hood of what we mean by technical. That said, however, if you are looking to break into product management from different discipline or different walk of life, you will need to learn certain things, right?

So the good news is it's very learnable. The jargon, the syntax of things like APIs and how they work or how the websites on the internet work and things like that, they're very learnable, but it's primarily about rigor in logic and thinking and systems. It's primarily about just curiosity and wanting to know how those things work.

And maybe not being afraid to just ramp up on things that you may not know about, but it's ultimately very learnable. So that's why I prefer to think about the core underlying skills that represent technicality, which is logic and system thinking versus just specific technical knowledge around a certain area.

Then C is the next letter and that's represents creativity. The reason why I think creativity is important is we often as product managers solve problems that have no clear answers and that have no clear data set that we can look at and say, Oh, this is what the data is telling us. So you have to make informed guesses, you have to make hypothesis, you have to make assumptions and clearly state them.

But oftentimes you find yourself in an uncharted territory. And I think that to move forward and not get blocked and just, experience the analysis paralysis, you have to approach it oftentimes from the place of creativity and the how might we, and the design thinking. So I definitely look for people who have that creative courage when I interview PMs, and I think that if you do have creativity in you, then you will definitely be leveraging it in product management.

And then K in HACK is my favorite one because it stands for the knife and the example will of course be from the art space. You know how Michelangelo used to say that it's very easy to make a sculpture. You just take a piece of marble and then cut off everything that doesn't belong. And that is the knife that I'm talking about because one of the hardest problems in product management is what not to build and what to say no to.

And the skill and the good news is also that the skill comes with experience. The more you use the knife, the better you get at it. But knowing what to cut off to make that beautiful sculpture out of a very unapproachable and vague piece of marble is something that I look for in interviews and for signals that people are structured and how they think about what is in scope versus what is not in scope to put it in PM speak. But primarily, like how do you distinguish signal from noise and make decisions around what should be there at the end? That's the long answer to the technical question. 

Hannah Clark: And I think it's a fantastic framework because you really cover all the bases of what are those core skills that are needed.

But what makes me so curious, I feel that being analytical and creative is relatively easy to screen when you talk about someone's background and the experiences that they have. How do you screen someone for humility and for that kind of critical ability to wield the knife? Because it is something that, it's a skill that I feel you really only can test that when you're really held up to a pressure point.

So what are the some of the ways that you evaluate a candidate early on before bringing them onto the team to see that they possess those necessary qualities?

Natalia Baryshnikova: Yeah, that's a great question. One of the easiest way to tell that someone is humble is they will tell you, I don't know. Those are the words that I feel like a lot of product managers, especially early on, are afraid to say.

However, that is one of the most important things that you can do to not only show that you are humble and intellectually honest, but also to create trust amongst your peers and stakeholders. Because, I don't know, it's a perfectly valid answer. Again, as product managers, we deal with problems all the time where we don't have clear answers.

And I think that being able to use that language and acknowledge like, Hey, I might be wrong, or I don't know, is very important. And you can definitely tell in interviews or early conversations with product managers that they don't strive to have all the answers just for the sake of having answers, because that sometimes happens too.

But that to me is a very good sign of humility. And in behavioral questions in particular, when you talk to folks about how they approach certain situations based on, again, the evidence and past examples, you also can clearly tell that they at least entertained the idea that they might be wrong, or they basically validated their assumptions.

Those are all good signs of humility. Also how people talk about others. One of my favorite questions, interviewing managers, if especially it's a very experienced manager and I ask him, well, who is the best product manager that you've ever worked with? And if a person has 20 years of career, but they don't mention an employee and they only mention my manager 20 years ago was the best.

And I'm like, well, what have you been doing 20 years if you haven't raised a product manager who is better than you? So that's another sign of humility because the best managers always bring up a person that they help raise as a professional and someone who worked for them, someone who is more junior than them, because oftentimes folks also like, Oh yeah, I'm so senior.

I can't say that my employee is better than me. That's also a good sign that humility might not be there. And for managers, that is particularly important in the product management space. And then for the knife, usually I try to gauge this by asking people about scenarios that they have considered when they're making certain decisions.

Because it is essentially a question about what do you say no to and how. And sometimes you see that people don't say no to things in their decision making. So going through scenarios and understanding the trade offs. So trade offs is usually a good conversation to figure that part out. I find that the best case can usually clearly articulate what did they say no to, which is a good sign that a person can think about software products in terms of using the knife.

Hannah Clark: That's fascinating. And I'm taking notes. I'm not planning on switching jobs anytime soon, but now I know to say if I am. 

So now let's talk a little bit about the post hiring process and for folks, entering an associate product management position or entering the space from a different background altogether, I think that there's a lot of theory around product management that you might learn from a course, but there's a lot that you can only learn from doing the job. What are some of those challenges, maybe rude awakenings that you feel that product managers should be prepared for in their first role?

Natalia Baryshnikova: Yeah, that's a great question. I asked my team and I said, Hey, I am going to record a podcast today. What do you think I should talk about? And one of the topics that I crowdsourced, thanks to a fantastic product manager on our team, was talking about resilience to change versus being stubborn and resilient when needed. 

Because like you said, product managers are often expected to be CEOs of their job, and what that means, you are supposed to have all the answers. However, how do you balance that with that intellectual humility that we talked about? Because if you're working with a team, they can see through the fact that you may, pretend like you have an answer, but you really don't.

And I see, especially more junior folks running into this a lot, because it's really hard to have that pressure and experience it for the first time. So you want to have all the answers, but one of the common traps that I've seen product managers are falling into is just pretending that you have the answers when you don't, rather than figuring out when to turn to curiosity and try to learn more and entertain, the possibility of being wrong and ask more questions. 

So my recommendation here is as you work with the team, show that humility a little bit, because ultimately, yes, you need to figure it out, but at the same time, knowing when to persevere and say, no, this is what we're doing because X, Y, and Z versus when to pause and ask questions and make sure that you understand perspectives of others and specific challenges that they're bringing out is a fine balance. 

My recommendation, do not over index on that first part where you have all the answers when in fact you don't. So try to find a more curiosity driven balance. And curiosity is always a good skill to leverage as a PM. Just wonder about things a little bit and that should get you on the right way.

The other one, the other cone pattern is communicating very clearly and uses simple language. That is especially true if you're communicating with executive stakeholders. I'll give you some specific examples. Sometimes you read pages and they say things like, we made solid progress. And I'm like, well, solid as opposed to liquid... 

Hannah Clark: Or gas?

Natalia Baryshnikova: Yeah. There's a lot of gaps. Whenever I see the word solid, there's a lot of gaps. It may sound funny, but ironically, we all fall into that trap because sometimes we don't have the right data to back up our claims and we want to make a case. We want to make a statement and we just hide our position behind words.

But what that results in one, you create a situation where what you're saying may be misinterpreted by different consumers of your narrative. So that creates already a challenge and confusion and potentially misalignment amongst your stakeholders. Two, if you're trying to present something to especially executives, it's really hard for them to consume that because if you don't explain it in simple and abstract terms, then they will think that you actually don't know what you're talking about. Because jargon is very often used to hide the truth.

And when you're dealing with someone who has very little time to understand and grope your problem space and what you're talking about and what you're proposing, I would just challenge all PMs, especially new ones, but all PLs really, to look at how you communicate in writing and also verbally and just ask yourself, can I make that message simpler?

Am I using words that may hide or obscure what I'm trying to say or can be misunderstood? And if you notice things like that, then that's something to definitely work on and potentially get rid of. And then the third thing that I would call out is also kind of basic, but also not. And it is about following up.

The biggest challenge because PMs have to do so many different things and have all those different streams of consciousness and various stakeholders is following up. Two primary reasons for this. One is that's what really separates great PMs from PMs who just let, threads get lost and therefore are not as good and conscientious in that regard.

But also it's remarkable how quickly things change. So sometimes you have a conversation with somebody and you think you're on the same page. But a month after you can no longer assume this because markets change so quickly, software changes so quickly. We all have seen how quickly AI, took over.

And I guarantee you that if somebody had a conversation pre-AI and then a month later, when AI was on full swing as a trend in the industry, they probably would land in a completely different conversations and outcomes for those conversations. That may be an exaggeration, of course, because that does not happen too often, but it's still a good example.

Following up and re-communicating and making sure that you're still on the same page, because I often find that, yeah, we talked to this team a year ago and they told us this, therefore we built this thing. And then there's so much stuff happened in between, which makes the thing we did completely irrelevant. So don't fall into that trap. Make sure that you pull up and re-communicate things as a PM. 

Hannah Clark: I think it applies to more than just the PM role as well. I think that a lot of us who find ourselves pulled in many directions could probably take that advice to heart. 

So as far as we've talked a little bit about the challenges, of course, of going into PM, what are some of the unexpected rewarding aspects of the job that you didn't expect going into product management, especially in software product management? Is there anything that you think that new PMs can look forward to as their career matures? 

Natalia Baryshnikova: Yeah, absolutely. I think that to me, a very important aspect of the job is still having fun. And I know that we often approach talking about product management from a perspective of responsibility and impact and how you can change the lives of users and it's all great and it's all very important. But at the same time, because you have to run a marathon of just being on all the time and being the CEO of that product, you have to find sustainable sources of energy for yourself not to burn out. 

And I find that when product managers do burn out is often because somewhere along that journey, they stop having fun. And fun is just an example of something that gives you energy. If you hate fun and you have something else giving you energy, then tap into that.

But Prime War Raiders is about finding that joy and sparkle, because I think that teams that ship the best products that I've ever seen, they all have that fun together. There's a little bit of magic that happens when humans play. And that is a concept that I think, again, we can learn from art. That's, there's always a little sparkle.

It's always very clear that somebody enjoyed doing this. And so that's why when we talk about product management, I really like to remove crafts, because craftsmanship is about that pride. But ultimately, if you have ever observed a craftsman or a craftswoman doing something, you know that they get joy, they get a kick out of it.

They are having fun. So that's something that I really find inspiring for myself. And I try to learn from various crafts and how people do things, because I think that if you're trying to understand how to make the world class products, you don't necessarily have to look at Mobile apps or anything of that nature.

You can also look at other things, maybe in the material world that people make that are world class, incredible quality. And again, ask yourself, what are the standards? What are they doing? How is it different? And so fun and happiness and pride of ownership over the craft is something that I find very compelling in other places.

I once took a small sabbatical when I went to Scotland and then I spent my time doing an apprenticeship at a Scottish distillery just to understand how do they make that world famous whiskey and what can we learn from it? And one of the things that I've learned is that they have fun. I mean, it's easy to do that when you are around, browse a whiskey all the time, but it's still, I think, so true for all other crafts where you have that joy and you have that fun. 

So that's something that I often see product managers are not necessarily thinking about, but as you're running that marathon and as you are trying to solve hard problems, just always remember to pause and think, am I having fun? Is my team having fun? Because if you are solving problems and you're having fun along the way, you're also going to end with better solutions to those problems. Because joy is felt throughout the delivery of our work. 

Hannah Clark: I think that you could not be more spot on. And when I think about the work that I'm the most proud of, it's always the stuff that brought me the most joy, that I got the most energy from, that other people felt the energy and also had a lot of fun making.

And on that note, speaking of fun, this has been so much fun and it's brought me a lot of joy to have this conversation. So thank you so much. 

Natalia Baryshnikova: Yeah. Thank you so much for having me. I think you just reminded me of one of my favorite quotes from David Bowie, who said that, like he never writes songs for others. He always writes songs for himself and what he discovered in his career, it is when he had joy in writing a song for himself, that's what landed the best with his audiences, but not the other way around. And so I think it kind of taps into the same construct all. Loving what you're doing and having fun and ultimately getting the world to love it.

So I wish that for all of the listeners of this podcast. And thank you so much for having me. 

Hannah Clark: Thank you so much, Natalia. It's a perfect closing. Thank you so much. 

Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.