This is how I help teams build, maintain, and improve products.
Product research starts with the future users of your product. It gets color from the state of your market. It concludes with the capabilities of your own team. I know I've done enough research when I understand the core outcomes that the product needs to create, why those outcomes matter, and how much work it's going to take to build a product that can deliver them. Conclusions must be shared in a formalized way to stakeholders and team members prior to product planning.
Products are developed and maintained by people, so the most important factor in any product venture is whether or not the people on the team are set up for success. Before the product planning begins, team members should have clearly-defined roles and expectations for working on the team (even if those roles are intentionally fluid), especially concerning what happens when their product begins to generate revenue. Managers and leadership should routinely set expectations for how they prefer to communicate and what they are expecting from the people they oversee. It goes without saying that the human beings who are donating their time and energy to a cause need support from structures that help them feel secure and safe. This includes things like clear remote-work policies, an enforced code of conduct, paid-time-off policies, reliable payroll, and reasonable benefits.
The goal of product planning is to create a shared vision of what a “working” product looks and feels like. Some targets will be straightforward enough to be built, while other targets require prototyping and iteration to find the right way to deliver a particular outcome. This method of planning requires the use of built-in margins, especially where the time of iteration is concerned. The best roadmap is a high-level document that can be shared and understood by all stakeholders, regardless of what software is used. If the company is small, I prefer to stick with short-term roadmaps of 6 months or less, whereas a larger company would require a 12+ month roadmap due to internal overhead.
Now we're ready to build. I prefer a sprint-based approach for tracking progress which, at minimum, begins with a sprint kickoff and ends with a retrospective. Daily stand-ups are helpful for creating accountability and personal feedback loops, but should not be conducted in a way that wastes time or feels like it's time meant for “reporting to the boss”. It's inevitable that some number of new tasks will be prioritized above the ones that were planned for, so the most important thing is to measure velocity and eliminate distractions as quickly and completely as possible. Teams at this stage are always in danger of being too "in the weeds" to notice if they are building in the wrong direction, so it's important for me to regularly re-iterate the plan and call out what's left to build.
Reports change depending on who is reading the report. The progress in each sprint should be documented within some sort of self-contained unit (Jira is popular for this task) and be paired with summary documentation and/or release notes that the entire company can access. Customers also need to know how the product is changing, so release notes need to be packaged in a way that is appropriate for public viewing. At each stage of development, it's important for myself and the team to verify that users are always getting the regular, valuable outcomes they expect from the product.