Just a heads up: On March 24, 2025, starting at 4:30pm CDT / 19:30 UTC, the site will be undergoing scheduled maintenance for a few hours. During this time, the site might be unavailable for a short while. Thanks for your patience.
How should I think about projects and their fidelity?
How should I think about projects and their fidelity?
July 26, 2021 edited
Should a product discovery project be a single product or an area? For example, should I make a new project that is workflows or should I make a project that is platform and workflows would be represented as views?
I'd be really interested in how others would proceed. This was actually my biggest dilemma when setting up my first project in Product Discovery.
My hunch was to dump all the related ideas into one project as as it may not be clear at the ideation phase how the ideas will be productized (e.g. single product, product + extensions, platform + products on top of the platform)
This is a debate I have been running through my head as well. I love how you can sort and group the Lists and Boards into Sections. At the company I PM at, we have multiple product lines and products. I am thinking of using one Product Discovery for it all because it would allow us to have the overall visibility at a client level or at a project macro level when initiatives are cross product line. I am thinking we could use the "Sections" so that a Product Manager can still work within their small set while also allowing the organization to have the overall view. For example, I am thinking sections like "Product Line A", "Product Line B", "Product X". I would then be able to have our larger enterprise clients as their own sections as well so "Enterprise Client A", etc. This would allow us to have "roadmaps" and lists per client when those clients have work in every product line.
Atlassian Team members are employees working across the company in a wide variety of roles.
August 9, 2021 edited
Great question. We've seen teams using both approaches: one project to rule them all, multiple projects. And we've seen both work. At this stage we don't have a definitive guide/recommendation for this - it's actually part of what we're learning in this alpha.
My 2 cents on this so far:
We've designed this to work well for teams using the Spotify-like squad model: teams who are autonomous, iterative, given goals-not-tasks, where engineers/designers/PM/stakeholders can make decisions out in the open.
I would use the level that makes sense for day-to-day collaboration, centered on the end user experience. E.g.
if you have teams that work on 2 separate products that don't overlap in terms of audience or functionality, it's probably best to keep them as separate projects - even if a stakeholder wants to see a consolidated view every month.
if you have 2 teams that are going after the same goals and deliver different parts of the same end-to-end user experience then I would keep them in the same project
Then there are shades of grey - and in this case I'd ask "how frequent is the collaboration between the teams in the different product areas?". If you need to stay tightly aligned, a single project probably makes more sense. Basically I'd model this based on the UX/team/collaboration aspects, more than the product/product line aspects.
The tools we give you to manage this today are:
You can create one or more projects.
You can create views with filters (e.g. "product area = X")
You can group views in sections (by team, by product area, by product)
3 comments