@valeria_andreevna@erika_buirai@klajko_dora Version management for backlogs? not sure. Back log is a kind of storage of ideas what would be good to have in future. Version management is more for the actual work on the projct
@valeria_andreevna@erika_buirai@medik Yes, you are right. I was just thinking of online whiteboard tools that is more complex and usable already in the planning stage with visualization of different versions (MVP, etc..) of a product. I think it is a great solution in agile product management process. You can see for example StoriesOnBoard, which is based on user story mapping method.
Just don't rush and keep going forward. Everything will come back on track with continuous efforts.
Have a great example of a product which I have faced same issues many times, but today it is one of the revolutionary products in Edtech industry: https://www.producthunt.com/post...
Backlogs should be sparse. Try to clear them out at regular intervals — at least once a year, ideally sooner. If a feature suggestion has been sitting in there for a long time and gets deleted, it will get re-added if it's important enough. Otherwise, you know that it was probably written in response to a particular situation. As a PM, you should be focusing your team on the long term, high value work.
Roadmaps have to exist for a variety of different stakeholders (and sometimes the same stakeholder needs to dive in), so you need to be able to roll up and unfurl your plan given the situation. So my advice here is to make sure that you've organized your tasks as much as possible upfront. Otherwise, you're in for a world of pain later when someone has a question about status.
@product_at_producthunt Thanks for sharing Michael. Gotta admit that our backlog can get dirty sometimes.
I do have a question for you if you don't mind: how long is your detailed roadmap? Not the high level vision stuff, but the roadmap that has lots of detail.
@between_team Since I'm still fairly new at PH, I'm not that far ahead yet here. In past lives when I'm using a two week sprint cycle, I like to be 2-4 weeks ahead of development. That means I'm honing upcoming tasks with design and giving myself some buffer so I can focus more on the strategic vision. It also means I'm not so far ahead that shifting priorities based on current development makes me feel bad that I've mapped out too much.
@product_at_producthunt Interesting, thanks for sharing Michael, we personally have a roadmap mapped out 1-2 months and it's a pain because of how much you have to change based on unforeseen variables.
Build two backlogs; one for your long-term roadmap and one for your current sprint. The long-term roadmap should include high level problems to be solved or planned product evolutions while the sprint backlog should include single-function features.
We build our long-term roadmap backlog every year based on our annual goals and we build our sprint backlog every six weeks based on our quarterly objectives and key results.
Having a weighted scoring mechnism has been one of the most important things I have implemented, the weighting helps keep the team focussed on what is important based on what the business is trying to achieve.
Trello board with lists of top product themes/domains (working on a personal finance product, so themes are "insights", "entry", "growth"...). Each list is organized by important and nice-to-have's items, separated by a fake "------" priority line. Every new release I pick up the important items from the themes I want to focus on ✌️🥸
Our company has software called "Bizixx" (https://bizixx.fatbit.com/?=pc) This helps in maintaining a track of all the tasks. You can set a task as a priority and manage your dashboard. You can mark a task as complete or put it on hold. It's an amazing Software by FATbit Technologies for employees as you can mark your leave and do much more to manage your work.
Hi all, there are three sides of this.
Feedback, internal requests, product roadmap. We focus on prioritizing what users really want in one place as a Producter.
Also, We provide a shared place for tech and non-tech teams to make product management more visible. Producter both helps product and customer-facing teams to make informed decisions backed by customer feedback.
For next-generation product companies: https://producter.co/
Although many teams have difficulty deciding if a product plan is necessary for an Agile environment, I can tell you that it is. There are many ways to make sure you get the most from your product roadmap.
It isn't easy to create a roadmap that works in any environment. This is especially true for Agile teams where there are frequent changes.
These are five tips that will help you create an agile product roadmap that is practical and usable.
1. Focus on the goals and not the features
2. Think first about product strategy
3. Create a narrative your team buys into
4. Please leave the details of the product backlog
5. Keep flexible
Once you have created your product roadmap, follow these five steps. It is essential to communicate it with your team so that everyone understands. Be aware that different team members may have different needs in terms of the information you share. Your developers will need more information about the tasks they are working on, while a higher-ranking executive may only need an overview of the strategy and the overall plan.
Avoid having a long backlog of things. Keep it simple and review it, if it won't be done in the next 2 quarters, get rid of it.
Be aggressive and review tasks weekly/every sprint. Review tasks every quarter on bigger things.
Map your ideas with customer feedback/requests, this helped us to weigh the impact and urgency as well as evaluate how we're solving customer needs and if that fits the strategic direction.
But first you do need some customer insights, which you can check out this tool for collecting different types of feedback http://usersnap.com/