Building up the confidence to change

They say it’s not the destination, it’s the journey. And whilst that is often not true for actual traveling (who loves a 12 hour flight?), it is definitely the way I like to look at my professional path, and this comes with a feeling of pride and a sensation of chaos.

I wrote before about being a generalist and how it is both wonderful and disturbing. When I started working in the SaaS industry 8 years ago as an account manager, I saw it as a good opportunity to be able to pay the tuition fees for my Master’s degree in Economics (I was writing a thesis on wine exports). Now I’m managing a product in a hyper-growth company. In the meantime I’ve lived in two different countries and learned a few lessons on leadership, mostly by failing at it. It’s been an interesting ride, only possible by constantly seeking discomfort and calculating risk. Unless you were born to be a risk-taker and/or have a really great safety net, striking a balance between these two factors is essential.

Being a young girl with a diploma from an Arts school, it’s hard to build up your confidence levels in a male-dominated industry where engineering talent is the market’s most valuable asset. To be honest, it’s hard to feel confident in any context. Also, when you finally get there, you have to face how other people struggle to deal with it. People tend to treat confidence as a personal trait, but like with any other skill, you can work to develop it. To me, the best way to train confidence is through learning, either horizontally (learning something completely new) or vertically (becoming really good at something you already know), but with a strong preference for the first option. There are a couple of things that help with that:

Being mentored by smart people

You can’t push for this – it’s a matter of luck. When I say smart I don’t necessarily mean booksmart (although – unpopular opinion these days – I find that helps), but someone who is capable of having a comprehensive world/market/company vision that is not tied to common biases and assumptions ranging from gender, age, education, family background (…) to your haircut and tone of voice. Someone who values your curiosity, your effort, your ability to organize thoughts and speech, who you feel comfortable talking to and learning from. I don’t like the expression role model as it doesn’t do a very good service to individuality, but someone who respects and protects your intellectual integrity. This is the only way you’ll feel safe asking questions.

Being open to learn autonomously

Indeed, asking questions may be the best way to learn and improve, but the first person you should be asking questions to is yourself. Research. Use technology to your advantage. Read. Try to come up with your own solution to the problem. And then go to others for validation – if you get it, you’ll feel incredible for having achieved that on your own. If you don’t, think about what needs to be done to improve that process for others: see if there’s a gap in an internal knowledge management platform that you can work on, if there’s some training that should have happened during onboarding. Turn your frustration into someone else’s accomplishment. Contribution makes everyone feel better.

Settling in

So the goal for me was to learn a new trade in a new company – switching from a leadership to an associate position – whilst working 100% remotely and raising a one-year-old in the midst of a pandemic.

Here are some the key learnings so far:

Users are your source of truth, not the Jira board

If you’re looking for a source of truth about product status, don’t trust the Jira board or sprint reviews – trust users. I also learnt that it is possible to be constantly in touch with your customer and yet not know how the product performs in real usage scenarios. This happens because, in B2B particularly, the person who buys your software is not necessarily the same who’s going to use it.

I don’t think you need to eat your own dogfood. User research offers a variety of techniques that will bring you closer to product usage reality. Just don’t settle with second-hand feedback, as it can be deceiving.

Observe with empathy, react with reason

It’s normal to feel bad when you see something you helped build fail its purpose. And yet this is a very likely outcome of user research. Being able to feel more empathy towards users than pride over your own choices and team work is a lesson I learned the hard way while working in customer success, providing mission-critical software for large enterprise. Being proud of your tech doesn’t pay your salary – happy customers do.

The customer is not a moron, she’s your wife. If it’s not working for them, don’t patronize – save some time to try to get to the root of the problem and come up with a fix. The fix could be a minor tech improvement or a completely new product vision – embrace change without seeing it as a personal or even a corporate failure. However, I think proportionality is also key, because trying to reinvent the wheel every 2 weeks is not sustainable.

Gain access and control

I’d argue that while you don’t need to be your product’s heaviest user, it is a good idea to check the state of the art every time something is deployed to production, even if it’s not a major feature. It’s not a matter of not trusting the QA process – it’s just that there are always tiny interaction details that you missed in the design stage. Iterating over mockups makes me nervous.

I’d also like to add a comment about feature flags. They are great to guarantee smooth feature rollouts to customers, but I found it crucial to have direct control over them: as a PM, I need the flexibility to enable or disable features without disrupting the development cycle. I needed the freedom to decide when to beta test a feature with a customer, or just to enable stuff for testing in internal production accounts.

Don’t fall into the Scrum trap

Scrum provides a framework to organize product development, not product management. It doesn’t offer a lot of guidance when it comes to discovering new features, prioritizing, aligning those priorities with management, making sure your solutions are tightly integrated with the product’s ecosystem, communicating new features to your stakeholders, choosing the best methods for user research, … the list goes on. It’s easy to fall into the trap of organizing our work around ceremonies and ceremony preparation. I adhere to Agile principles but dread the ritualistic vibe it brings to team work. A framework (any framework) is supposed to make your job easier, not define it (this one goes out to all of you hiring product owners).

Build and communicate a vision

Another Agile trap, which I believe comes from a misinterpretation of its main principles, is that long-term planning and vision statements are no longer useful. Value is more easily delivered if you adopt short cycles and constant iteration. I don’t argue with this, but I do argue that this is not incompatible with having a long-term vision for a product. MVPs deliver value, but they don’t inspire people. Having that inspirational story to tell is helpful to gain internal alignment, to deliver marketing messaging, to motivate. A vision is not a one-time commitment – it’s a compass for everyday decisions and is constantly evolving.

Go for that swim

On a final note – I live by the beach in the north of Portugal, where sea temperatures range between 15-17ºC in summer months. It’s beautiful and cold. I stand for long minutes with my feet on the wet sand getting mentally ready to take a plunge. Then I look to the side and there’s a group of kids just playing around in the water, completely indifferent to the fact that it’s 20ºC below their body temperature. I feel silly and old. But I’m not, so I go for it.

The same goes for the job. I’m overly conscious of my limitations, and that frustrates me. But then I realise I’m just a kid, I can learn anything. So I just go for that swim.