Show HN: I built my own PM tool after trying Trello, Asana, ClickUp, etc.

It makes a difference in establishing trust with your potential customers, you're asking people to connect their Google account and give you money. Who are you? What is your background? Are you VC backed or bootstrapped? I know nothing about your company, why should I give you money? Please don't take this the wrong way, your product looks great! Just helping you with some constructive feedback.

JIRA pretty much exists on the promise that it can translate a git commit+test into "project Y is now Z% done." Everyone moans about how much it sucks, yet the last five products I've worked on have used it because behind the excessive complexity is a really powerful tool for managing teams and CI/CD. It sure isn't Product pushing for JIRA to be used, because the built-in roadmapping features are awful.

I think you need to put a lot of work into making the JIRA and Salesforce integrations incredibly clean, not try to get the engineers and biz dev folks to log into a single portal. Look at each of those tools with an editor's eye and figure out what is going to survive into the PM's representation and what is un-necessary complexity.

--------------------------------

Going into specifics of how I tend to run this... Personally, I've found the VMOST[1] (Vision, Mission, Objective, Strategy, Tactic) stack to be the best way of linking vision to roadmap - as lightweight as feasible while providing structure. I rename the pieces to (Vision, Objective, Key Result, Focus Area, Initiative) which tend to be more understandable to most people. This gets bonus points for easily tying into the OKR planning process that many companies run now.

That gives basically a 3-layer strategy pyramid:

* Vision: What we think the best future would look like, where we help someone do something valuable. Maybe 3 years away.

* OKRs: 3ish Objectives that we think will get us much closer to that Vision if we achieve them. For each of those, 3ish Key Results that are objective measures that let us know we have hit our Objectives or are at least going in the right direction at speed.

* Work: 2ish Focus Areas for each Objective that are consensus hypotheses of directionally how we would achieve the Key Results. Then within each Focus Area, 3-5 initiatives.

Put in time order, these Initiatives form the Roadmap. The exact scale of what counts as an Initiative depends on the team and what we're doing, but some examples: A Feature or Epic. Getting a key partnership signed. Launching a marketing campaign. Opening an office.

All of those need to be tracked in one place so that we know overall progress, track inter-function dependencies, and can have serious conversations about what's working and what isn't. It needs to be in one place so that I can ask "Is anyone doing literally anything that is not in this view? Why are you doing that thing?" The answer is usually either "SVP so-and-so said their thing was really important" or "we need to do that operationally so the current product doesn't fall apart." In which case I need to have a conversation with SVP so-and-so, and we need to explicitly decide that we are or are not ok with the current product falling apart, and incorporate support into the stack.

I always do this manually using a Wiki like Confluence, because integrations don't work right and I'm not taking time away from people who actually do things to play bookkeeping games.

[1] https://bad.tools/library/toolkits/vmost/

first, it uses "PM" in the title, but note that upbase is a project management tool, not a product one. project management tooling could be viewed as a subset of product, but in other ways, project management is a related, but separate discipline.

second, if your product management processes deliver no value to your colleagues, then you may need to work on that, perhaps more as an organization than an individual pm. the product management process and tooling should absolutely deliver value to developers, designers, and other individual contributors. most pertinently, tracking velocity is for the team first and foremost, and secondarily for others. it's like keeping score in basketball--it's how the team knows how it's doing.

third, it may be big and "enterprisey", but jira is just fine for product/project management. when folks complain about jira, ~99% of the time, it's a complaint about the process and people involved, but turned toward the tool because it's hard to criticize the offending party directly.

i do agree that product management tooling is secondary to sales, marketing, finance, accounting, etc., and so must interface with those other systems for "truth" rather than being a system of record.

There is an optimal amount of work breakdown before starting the work. It sounds like you wish there was slightly more detail and some type of infinitely nesting tasks.

Sometimes it's not worth putting everything into a ticketing system.