6 ms·

Firstly, congratulations on your launch! My personal opinion as a Product Manager is that there is no all-in-one tool, there never will be an all-in-one tool,

Firstly, congratulations on your launch! My personal opinion as a Product Manager is that there is no all-in-one tool, there never will be an all-in-one tool, and anyone promising an all-in-one tool has some significant blinders on around the job functions they have been exposed to. Sales will use Salesforce. Engineering will use JIRA. And Product will use some generic roadmap-first tool like Asana, Trello, Miro, Monday, or MS Project. Product will beg everyone to use their tool, but no one will because it's for looking at work, not executing on it. Product will not understand because we Product Managers don't actually DO things, we talk to people, organize ideas at a coarse level - and we have a simple tool that articulates the vision perfectly! Except it doesn't automatically integrate with the CI/CD pipeline, it doesn't automatically log the last touch with a high-priority prospect, it doesn't pass designs from the designer to the UX engineer. It doesn't actually DO anything. It becomes just another SaaS platform in our Okta stack that only the PMs look at - and it gets out of sync with the actual reality reflected in the other SaaS offerings. And the reason it doesn't do those things is because the people who built it thought that THEY were the ones who could build the all-in-one project management tool and all those sales people, engineers, designers, lawyers, and marketing writers would log in to theirs. Insert relevant XKCD about standards here. The truth is no PM tool will ever be the system of record for the actual work, but everyone is afraid that the complexity of integrating with others will turn them into JIRA. So we get these vaguely opinionated ways of moving around and arranging candy-colored cards, and those cards never quite show us the state of the project we are managing, so we have to bug people to "update their status in <Monday/Asana/Trello>" before the weekly meeting. Which they don't want to do because it delivers no value to THEM. Which is all a long-winded way of saying - please think about how a piece of work from each of those functions might be represented in your view, and how that integration would happen automatically.

ChikkaChiChi 4y ago
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.
leokennis 4y ago
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”?
- drc500free 4y ago
  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/ https://bad.tools/library/toolkits/vmost/
avip 4y ago
#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".
clairity 4y ago
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.
deleted 4y ago
[deleted]
tonypham 4y ago
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.
- drc500free 4y ago
  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?
  - tonypham 4y ago
    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.
jyrkesh 4y ago
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

ChikkaChiChi 4y ago

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.

leokennis 4y ago

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

drc500free 4y ago
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/ https://bad.tools/library/toolkits/vmost/

avip 4y ago

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

clairity 4y ago

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.

deleted 4y ago

[deleted]

tonypham 4y ago

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.

drc500free 4y ago
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?
- tonypham 4y ago
  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.

jyrkesh 4y ago

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