12 things I learnt in my first year as a startup Product Manager

This is my first blog post ever. It’s a reflection on the most valuable lessons I learnt working as a Product Manager at a B2E startup called RadFrame.

Heads up: This is a repost of my ages old Medium post so it might read a little weird. I’m re-posting it here because of 2 reasons:

  1. I want to make my substack the one place for all my writing from here on.

  2. I think it’s still relevant.

On to the post…

Btw, this isn’t necessarily a list of things you need to be a good PM. There’s plenty that’s been written on that — read anything by Ken Norton or Lenny Rachitsky and also see here, here, and here.

This list is just unadulterated learnings from my experience, in no particular order.

1. As a PM, it’s your job to set the framework for action

Everyone in your team wants to do the work (most of the time — in my experience anyway). What I’ve learnt is that sometimes people struggle with where, or how to start approaching complex problems. This is where Product Managers come in. People will look to you for a course of action, and it is your job to deliver that.

Product Managers set the agenda and lead the conversation with a relentless focus on outcomes. For meetings, for user interviews, for every conversation. We break down problems into smaller, actionable chunks, document (often shitty) processes and hold people accountable for executing on key decisions. We also do important things no one else wants to do.

2. Preparation is everything (especially if you want good meetings)

I learnt this the hard way. Because we work across so many areas of a business, meetings are an inescapable fact of PM life.

When I started working at RadFrame, I used to rock up to run meetings without any prep. I figured, everyone invited would’ve digested the material, already have context and the decisions will just magically happen. Right?

Wrong. What often ensued was a 2 hour shit soup of circular conversation with no decisions or outcomes.

It got tiring. Megan (the CEO at the time) brought this up during our first feedback session and it has stuck with me ever since.

Meetings are for decisions. Otherwise they suck. So you need to prepare in advance to make it as easy as possible for your team to make shared decisions.

Preparation is what helps you set a framework for action.

So, do the user research – in advance.

Understand what your competitors are doing – in advance.

Articulate your vision, decision criteria, and expected outcomes – in advance.

People will thank you for it. Hell, you might even start enjoying meetings…

3. Data is a means to an end — be data informed, not just data driven

This has been said before, but sometimes it seems abstract. It’s not.

You need to consider your design intuition, qualitative AND quantitative feedback to make successful product decisions and ship useful iterations to your users.

At RadFrame, we set a goal for each team member to speak to at least 1 user/week, but we also reviewed analytics data from Intercom, Mixpanel and Amplitude weekly. We used a synthesis of all of this data to make decisions during our quarterly strategy sessions.

Good product design comes from striking the right balance between data, empathy and intuition.

From Alastair Simpson @Atlassian

So use data and analytics, but also talk to your users often. And learn to trust your gut, because you will never have complete or perfect information. Be data informed.

4. Seek simplicity but distrust it

There are a lot of ways to interpret this quote, but it applies in a certain way for Product Managers.

Simple means you get to the essence, but it also means you lose the nuance. You have to switch between these 2 depending on the context and who you’re communicating or engaging with.

For example, when you’re describing your roadmap to the CEO (or other key stakeholder), you want to emphasise, as simply as possible, the net benefits of the features in your roadmap and the problems they solve for your users. But when talking to your dev team about the same features, you need to get down into the details about every single user story — the interactions, the UI spec, the shadow on hover, the load time and all the rest of it.

This ability to zoom in and out on demand is a key ability you need to have as a PM.

Develop it. Nurture it.

5. Embrace the suck

Sorry to break this one to you, but PMs need to be incredibly resilient and possess a high level of grit.

Be ready to do mundane things that are important – because if you don’t, no one else will.

6. Be human

Acknowledge, say thank you, be nice, be candid and create an environment of psychological safety.

In your conversations, in your feedback, in your writing, in your interactions. In everything.

People appreciate and are motivated by small gestures like these more than you’d think.

Remember, a high performing team needs to work together to get shit done. And it’s your job to create an environment to make that happen.

7. Expose yourself to a diversity of experiences to be more creative

As a Product Manager, you do creative work. In essence, creativity is about joining dots, and like anything, with deliberate practice, you can become more creative.

Creativity = joining dots with reason and intuition

To be more creative is to be better at joining non-obvious dots. Reading between the lines, making connections between things you wouldn’t normally associate with each other.

But to be more creative, you need expose yourself to a variety of experiences. Because diverse experiences expand the range of possibilities you can imagine.

From the Creative Thinker’s Exercise Book

And to state the obvious, new experiences also keep life interesting. So find that side hustle, volunteer for causes you believe in, travel, learn how to tap dance. Just do something that you wouldn’t normally do.

This is my personal experience. I moved countries when I was 14. I am terrible at dance, yet I’m learning hip hop at the moment. I am a personal trainer and teach yoga in my free time. I also moonlight on social impact projects, mostly helping for-purpose organisations with product work. And all of this helps me expand my creativity at work everyday.

8. Learn what’s possible for your developers and with your tech stack

This is by far the most common piece of advice from all the product mentors I’ve had (there are several). And it’s a crucial part of being a PM.

As a PM, you need to traverse the intersection of technology, the business and user needs.No, you don’t need to learn how to code to be a PM (although I hear it can help). But you definitely need to understand what’s possible with the tech that you do have.

Trust me, go out of your way to do this, and your dev team will respect you for it. This is a key lesson I learnt early on from RadFrame CTO Bryce. In real terms, the velocity gains with this simple move can be exhilarating.

If you’re a product person with a non-technical background like me (I studied International Relations at university), then you might find this course helpful. At the time of writing, I’m just about halfway through it.

9. Eat feedback for breakfast

Feedback is the most important component of deliberate practice. It’s your secret weapon to constantly levelling up — both the products that you’re building and yourself as a PM.

So seek and action feedback, voraciously.

There’s another reason. As humans, we all have biases. Which means that we often miss learning opportunities, no matter how hard we try to mitigate against this. When you seek someone’s honest perspective on how you can improve in the future (i.e. get feedback), you accelerate your learning.

Oh, and don’t take feedback personally — especially the constructive kind. The person who gave you that feedback is doing you a favour. Make sure to thank them.

10. Questions > statements

In most situations of disagreement, the natural tendency is to assert your view and just hope that whoever you are arguing with will change their mind. At least this is what I used to think.

Funnily enough, in those situations, especially during heated disagreements, asserting your opinion is the worst thing you can do. It leads to further divergence, and poorer outcomes, almost every single time.

Read this comic if you don’t know about the backfire effect. It’s life-changing.

So what should you do instead? If you really need to change someone’s mind, you don’t have to compromise.

Genuinely empathise with their view. Align on the problem. And then ask good questions to trigger critical introspection. For example, instead of asserting,

We should display the templates on the first screen because it clearly solves the accessibility problem for users.


I understand that having all the templates on the same screen will make the UX cluttered. But we know users have trouble finding the templates they want fast. What is the best way to make templates accessible to users on the first screen?

Then get out of the way of the answer.

In essence, it’s just reframing. In my experience, it’s one of the most effective ways to persuade someone to reconsider their view, without making them hate you for it.

11. Design Thinking, Lean Startup and Agile together give you superpowers

Design Thinking, Lean Startup and Agile together give you a powerful way to solve complex problems. But to a large extent, all 3 have lost meaning in their transition to becoming buzzwords.

For me at least, it’s all about the mindset. Without the mindset, the underlying processes, rituals and tools fall apart. So start putting the key components of the mindset in practice:

  • Embrace and navigate ambiguity

  • Experiment (often and fast)

  • Learn from others (both people and contexts)

  • Synthesise information from a variety of sources

  • Communicate early, often and deliberately

  • Align on the problem(s)

  • Adapt to change (as it happens)

Understanding how DT, Lean Startup and Agile fit together is a whole different discussion. If you want to dive deeper into that wormhole, I highly recommend you start here.

12. Bring everyone along for the journey

When designing and building products, there will be a LOT of people (think users, customers, your team and other internal stakeholders) who you’ll co-design with, need to seek feedback/decisions from and keep updated.

No one likes being left out. I’d recommend erring on the side of over communication, and bringing as many people as possible along with you on the journey.

This is exhausting. Sometimes communication is even counterproductive (e.g. when you get blocked because the CEO doesn’t like the font…).

But you just need to figure out a way to balance this with getting shit done. Because it’s ultimately people who will care about, rave about, celebrate a successful outcome. Remember you’re still designing with and for humans.

13. Bonus: Product Managers aim to over-deliver

I know I said there were 12, but this one’s too important to leave out.

You’re responsible for your own learning – manage it like a product.

I try to manage mine that way. I set a vision, identify key trends/interests, talk to successful PMs about key skills that a PM needs to have today and will need to have in the future. And I revisit and review these every few months.

I also try to read as much as possible. This is what my reading Trello board looks like at the time of writing:

There are many reasons to read widely. Every changemaker I admire reads a lot. Reading widely and across domains also helps with building a broad repertoire for creative work.

As Product Managers, we’re meant to dream, design and build the future. That’s how I see it anyway. One way I keep a pulse on what the future could look like is through constant learning.

Want more like this? I plan to write a bunch more so make sure you subscribe to keep up with the latest 👉🏽

That’s the end of the list — thank you for reading! This is my first public piece ever so if you have feedback on the content or my writing, please comment, I’d love to hear it (remember #9, eat feedback for breakfast).

Thank you to Bryce, Megan and the Fusion Labs team for the awesome opportunity to learn all of this. And also to Julia, Joël, Ivan, Zach and Tim for reviewing the drafts — you rock.