#21 🛠 Should startup PMs focus on internal tools?
With limited PM capacity in a startup, it's not always clear how to prioritize internal tools relative to customer-facing tools. Here's my take.
Should startup PMs focus on internal tools?
I got a question from a friend who is a cofounder/CPO of a fast growing startup last week and figured this thread might be interesting for people because I don’t see internal tooling get discussed often enough in PM circles.
Note: I considered writing it out as a post but the Q&A format seems to capture the thought process well so let’s just go with it.
Friend:
Would love your opinion. Do you proactively PM internal products/admin panels, etc?
Me:
Depends on how critical it is for the business!
Also, depends how clear the need is: if the necessary functionality is clear and you can trust an engineer to build what's needed, I wouldn't spend time on it.
My first full time PM role was at Breeze (before Ford acquired us and we became Canvas) where I spent the first six months PMing an internal fleet management tool from scratch. The CEO later told me that without this fleet management tool he doesn't think we would have been acquired.
For a business like ours in the car space, having a fleet management tool (even if internal) demonstrated thought leadership around how to manage a very operationally complex business with software.
If you think you can differentiate yourself in the space by investing in better internal tools to solve operational issues, then you probably want to active PM internal tools to make sure they're solving the most important problems with the right long-term vision in mind.
Friend:
That makes a lot of sense - sounds like those decisions are intentional and strategic. I wonder though. Do you proportion development energy between different backlogs or weave other team priorities into a single backlog? For example: if you team advocates for development of finance reporting tools, how do you determine priority between that and product team priorities?
Me:
That’s the crux of prioritization. This is also why companies end up splitting up the product team into two teams so that each one focuses on a different strategic area. At Breeze, my team was not only separate from the rest of the eng team, we even got our own apartment for the seven of us that we used as a separate office. If the internal tooling is of strategic importance you should incentivize an entire team to focus on it without needing to evaluate how it compares to other priorities.
If you don’t see the internal tooling as of strategic importance, then you can strike a goal of having x% of the monthly effort/bandwidth dedicated to internal tooling. Something like 20% sounds reasonable (1 FT engineer out of a team of 5).
Prioritization ultimately comes down to impact. It’s not about the feature/project. It’s about what the feature/project enables.
Friend:
100% makes sense. We do a percent on internal needs managed via separate backlogs but I ultimately wave them into a single backlog to make priority decisions between them. But yeah curious other ways to do it. Sounds like you dedicate a percentage or make priorities compete. I feel like in general, you can make more optimal decisions doing so rather than always targeting a %. But others on my team disagree. There is strategic importance with some but not all items.
Also, teams right now manage the priority of their backlogs. Team leaders are not PMs. Any thoughts on that?
Me:
If team leaders who manage the priority of their backlogs are not PMs,
1) what are they?
2) do you trust their ability to make the right prioritization decisions?
Friend:
Head of ops manages ops priorities, for example, operations includes account management, support, etc. and we colab in it and are generally aligned, but still, priorities of that backlog are ultimately made by them and the PM (me) help out.
We target some percentage of ops work since we leverage ops and internal tools to reach service levels for contracts, but I general am starting to think I need to much more rigorously PM that backlog because I think we can get a higher bang/buck. Basically thinking I should proactively do “user research” on the internal members to understand their problems and where I can better empower them/save time rather then waiting till they realize theirs issues. Thoughts?
And to your second question - I generally trust prioritization decisions, yes, but I still don’t think they are as optimal as possible because there isn’t PMing with quite the same level of rigor that a PM might bring.
Me:
Yeah, doing internal research to identify the biggest problem you might be able to solve with software is exactly how we went about figuring out what a fleet management tool should be at Breeze. So that approach has certainly worked for me!
Friend:
^^ That's awesome. Been bouncing these ideas around and I think I have a much better understanding of it now, and it definitely seems like as internal needs become of strategic importance, it certainly makes sense to proactively solve and prioritize those problems as you did at Breeze. Thanks for the help here.