Hacker News Reader

#facts. Great comment.

How many times have we seen PMs trying to brute-force JIRA (et. al) into a project management tool using weird plugins that don't co-exist peacefully. This always fails, and PMs either retreat to their own trusted platforms (if you're lucky), or in severe cases start asking everybody for "excel summary" or some "one pager" to reveal that holy "project status".

This tracks closely to my experiences as well. Managers need to understand that managing upwards and laterally is equally as important as managing downwards. If your peers and bosses aren't fluent in your team's tool of choice, it is your responsibility to be the translation layer to a tool that works for them.

This is the only way to truly achieve the type of transparency we're all searching for.

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.

I definitely hear you on the product/project distinction. It's sort of adjacent, it's sort of a subset. To me, project management is the cat-herding part of execution. And that's exactly the part where trying to get other functions to log work in the "catch-all PM system" falls apart, whether you're a project manager or a product manager juggling tickets.

You can either run it out of JIRA and only manage the work of software engineers, or you can run it out of something else and be out of sync. Probably the biggest mental trap PMs of both kinds fall into is running all status checks out of JIRA and ignoring everything about their product/project/career that isn't accomplished by pushing code to prod.

I find the people do get value out of what Product brings to the table, and absolutely buy into the vision (especially if they help define it). That doesn't make them motivated to maintain an additional project tracker for a status meeting. They also don't like flossing, even though they hate cavities.

And that's what we're talking about at the end of the day, because JIRA IS really good at what it does - either everyone gets aboard the JIRA train, or the engineers track all their tickets in something less powerful, or you ask the engineers to use JIRA AND something else.

Most established places go with the first option and then their only muscle is "ship code," many startups go with the second option until they realize they actually need JIRA after all. Then some PM (of one kind or the other) has to make the third option work so that they stop getting blindsided by the compliance work or the marketing campaign.

> when folks complain about jira, ~99% of the time, it's a complaint about the process and people

Not exactly. Most of the time, when people complain about JIRA they are complaining about its complexity, which gets exacerbated by PM's attempts to customize the system to their own liking, turning it into spaghetti. Even when the actual intended process is fine. That, and the slowness, subpar UI and arcane permissions system.

The new UI is almost tolerable, but the permissions and workflow systems I totally agree, a convoluted mess

Thanks for taking the time to share your thoughts, drc500free. That is a very interesting comment.

For solos and small teams with simple workflows, I think they'll be able to use some types of "all-in-one" tools to manage their work. For large teams with complex processes, I agree with you that there are no all-in-one tools that could work well for all functions.

Thanks, and best of luck! It's at least 10,000 times easier to lob comments your way than actually build the thing, so please take everything with a grain of salt.

I've seen a lot of Monday/Asana/Trello islands in larger orgs, where someone got a foothold for their 3-10 person team but now it can't ever scale. To some extent, using those tools is betting that you'll never actually be successful (if success will require scaling the people/functions that need to be involved). What's the plan for your customers once their thing works and they want to grow?

Thanks. I think if they managed to get Upbase works for them in the beginning, then they'd have no problem then they grow a bit. Unless they grow too big, too fast, then they might need to find another solution.

My vision for the product is to serve solos and small teams, so we'll try to keep everything clean and simple.

Thanks again for joining the conversation here.

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”?

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/

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...

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.

> how do you translate git commits and tests run to “project Y is now Z% done”?

You don't, because in most cases, for anything that has the scale of a "project", nobody knows how many commits it will take for it to be done.

Crushed it, you're spot on.

I've found the lesser of two evils to be that Product integrate as closely as possible with engineering, which means using either Jira or GitHub issues for high"er" level deliverables. You have to be careful not to use too much of the textbook PM speak--"As a <user>, I can do <new novel stuff> with the platform"--but if you orient yourself around the logical scoping of engineering work, it's a whole hell of a lot easier for engineers to tie their own work items into the progress (or unfortunate lack thereof) that all of us are inevitably expected to report up to our various business leaders.

That does require some technical acumen. I'm the first to admit that I don't have any of the formal bona fides for said acumen (and I deal with a great deal of imposter syndrome as a result). But when I listen to the engineers, understand their technical blockers, AND colocate our work items, I usually have an easier time.

And yeah, I still gotta copy/paste a bunch of shit into Sheets/Slides for management