4 ms·

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 o

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.

drc500free 4y ago
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.
ricardobeat 4y ago
> 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.
- qiller 4y ago
  The new UI is almost tolerable, but the permissions and workflow systems I totally agree, a convoluted mess

drc500free 4y ago

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.

ricardobeat 4y ago

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

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