After 4 exciting years, I’m parting ways with Metabase. It’s been a fulfilling run, working with smart people to build the most delightful (or at least, least migraine-inducing) business intelligence tool out there, all while watching the team grow from 25 → 100+ employees.

When I joined Metabase as the 1st PM under our VP of Product, I was still a much more capable data scientist than product manager. I didn’t have deep experience as a PM, and I had to earn my chops on the job. There was risk involved on both sides, and looking back, all I can be is grateful it worked out how it did. I'm excited about what comes next, but before that, I would be remiss if I didn’t take a beat to reflect on what I learned during my time. So here are some of my favorite takeaways, both for future-Conor, and anyone else out there.

Shippable Units of Value

Slice up projects to ensure are shipping value as early as possible. This is critical as it not only enables you to ship faster, it also mitigates the risk that comes with spending a long time trying to build the One Perfect Thing that may or may not resonate. It's also way more fun!

Getting to a place where you have shippable units of value however, is a bit of both art and science. One thing I found is that it's best to think about projects or initiatives through this frame as early as possible, and collaborate closely with engineering during this time. How the project is structured or shaped is the biggest factor in how it can be broken out. If a "unit" is going to take multiple months, there's a good chance you aren't being creative enough.

Force for Progress

Done right, product management serves as a force for progress across different functions. The most effective lever for this in my time was short feedback loops and close collaboration. Throwing things over a wall and hoping to get back what you expect does not work, while the inverse, communicating clearly and frequently, sharing incremental updates, gut-checking alignment ahead of time, leads to good results much more often.

Early at Metabase, I was much more hesitant to check-in on things and ask questions. As I got more comfortable, I would grab teammates for a quick huddle or hit them up with questions often on a daily basis. I'd like to think this helped us ship good product, but at the very least, it helped avoid U-turns.

Articulating Problems + Strategy

Product docs and “arcs” as we called them are quite useful, particularly as a forcing function for thinking through a crisp definition of the problem (without being too prescriptive of the solution) or clearly stating a “Point B” and the intended strategy for getting there. I saw my own understanding of these artifacts evolve over my time. Take “arcs” or “initiatives” as an example:

  • First attempt: “Visualizations: Opportunities + Plan” → No strategy outlining the thinking for how we’ll get there.
  • Second attempt: “Visualizations: Opportunities + Strategy + Plan” → No depiction of an endpoint. Will we work on this forever?
  • Third attempt: “Offer more expressiveness for viz creators: Point A + Point B + Strategy + Plan” → Framed around a solvable problem, with a strategy for how we'll get there, and endpoint that we aim to achieve.

I thought I knew what “strategy” meant before, but every time I tried to articulate my thinking it came out as a string of projects. It wasn’t until I was nudged to read Good Strategy Bad Strategy and applied it to the work we were doing, that things started to click for me.

Putting on Running Shoes

Business Intelligence is a pretty darn complex domain. The magic under the hood that needs to happen for a horizontal analytics tool to do it’s job is quite a lot. There’s millions of permutations of databases, modeling, queries, visualizations, settings, and more to consider. Even coming from a data science background, all the legos at play were largely opaque to me at first. And I was fine with that. I was doing my job, engineers were doing theirs.

As soon as I started taking moving to more technical product areas and taking on more complex initiatives, things got tricky. I was unable to be a “force for progress” since I lacked understanding. Now I’m much better at recognizing when I need to go deep so I can take off my "sandals," and put on my "running shoes," grab an engineer and talk through it, write through it, until I'm comfortable enough to move things forward like I should.

Chill User Experiences

Did I mention BI is pretty complex? Our differentiator was that it felt usable for non-technical folks. This is reflected in the Zen of Metabase well, and paired with the idea that products should be opinionated, it leads to some cool outcomes.

For example: Why add yet another setting, and the complexity and cognitive load that comes with it, when you have a strong opinion about what’s best? And if a setting is required, why make the user think about it when the system often has the information to make that call?

Arguably this framing is what resonated to me most at Metabase, and will stick with me over time. It’s a tough battle balancing new features, scaling to enterprise, and all that, with keeping the core of the product as “chill” and usable as possible, but it’s a fun battle that pays dividends.

Ambiguous Projects

Ambiguous projects are tough. When the problem or use case you are solving for is unclear, everything else is 100x harder. Even when you have that nailed down, reasoning through a huge solution space can be tricky as well. I’m still figuring this piece out, but I did see a lot of progress in my ability to steer these types of projects over my time. Some things that helped were:

  • Goals and non-goals to point in the right direction.
  • Open questions listed out and resolved through prototyping, design, product thinking, or research.
  • Start with only the crux as a slice. Mock out anything that’s not risky from an implementation or product standpoint. It should feel like a toy at first. It won’t be connected to everything, but people should want to use it and be disappointed they can’t.
  • When that's feeling good: Map out adjacent slices, middle-out, to take on next. Keep iterating for usability and completeness.

Miscellaneous Thoughts

Lastly, I’ll leave you with some stray ideas and learnings. No need for waxing poetic about these:

  • Walking the line between thoughtful and moving fast at a startup is tough. I think we did it fairly well, but it requires being very intentional about when to “go” and “pause and think” at all times.
  • I worked with people from all sorts of cultures, as we spanned 30+ countries last I checked. It was challenging, but more than that, incredibly cool. I learned a lot about the world and how people think.
  • Open source is awesome. I’ve never gotten so much feedback and interacted with so many caring customers on a daily basis.

Conclusion

I’m sure I’m forgetting a bunch, and recency bias is a hell of a drug, but that’ll have to do as a stab at putting four exciting years into words. I’ll continue rooting on the team at Metabase, and I’m excited to see what they cook up next.

As for myself, more to come! I’m actively exploring opportunities and figuring out what I want to get into next. Shoot me an email if you’re interested in chatting or simply want to say what’s up. Feels good to be writing again. Godspeed, folks.

Thanks for reading! If you enjoyed this post, you can subscribe to get future ones like it delivered straight to your inbox. 📫