That is super interesting. To build “the one tool” you’d then need to actually build five tools (one with tickets and commits and pipelines for engineers, one for sales etc.) and find a way to “translate” from one to the other.
Like, how do you translate git commits and tests run to “project Y is now Z% done”?
Did this in a shortlived startup 20 yrs ago. Other cofounder was the ideas guy. Pitch was to roll up granular, factual project achievements up into reporting data , and cascade objectives down. This avoids the red/amber/green fictional layer between PMs and sponsors.
Learned two interesting things
- if your tool mandates a philosophy or process, you massively shrink your market
- real pms , sponsors and engineer s buffer their risk by selectively disclosing information. They don't want a permanent record of open, granular outcome information unless they are in a very mature company.
Two really insightful learnings, especially that second one. A lot of meetings are pageantry, with decisions made through backchannels and off-the-record pre-meetings. Moving from a meeting to an online system doesn't remove that need.
I worked on an HR system recently, and "continual feedback" is all the rage. Folks have realized that those annual reviews and PIPs are completely divorced from reality - if we gave people continuous, incremental feedback they could course correct much more regularly. That ought to reduce the emotional shock of a PIP or a bad review, and also the time lost before the employee improves.
So performance review systems have started adding the ability to officially record weekly 1:1 meeting notes, and then getting confused that no one is using this oft-requested feature. Of course any honest feedback is purely verbal, or stored in shared documents kept as far away from HR as possible. The very fact that it's an Official HR Record makes it completely useless for purposes of getting truly honest feedback in there.
We do OK on this using the GitHub-Jira plugins. Put the ticket number in the commit message, and follow that commit progress towards the master branch, and you can get a (coarse) sense of "some progress has been made" and "this will be included in the next release." Of course if the initial PR is full of bugs and 3 or 4 follow up commits are needed...
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.
Like, how do you translate git commits and tests run to “project Y is now Z% done”?