Do you find that product requirements degrade over time?

Question

At work I have designed a few products from end to end (frontend, backend, machine learning systems, associated microservices, etc.) and with that is always a discrete list of features, user stories, etc. Perhaps the documentation could be higher quality, but what I deliver to my team is essentially a checklist of tasks to be done in order to get the product to a "completed" state.However, I'm starting to believe that stakeholders are not reading these documents because I will have meetings with the junior engineers later where the work that was assigned to them falls short of what was documented (maybe implements 75% of the features, or uses a substandard implementation of a feature), or sometimes they have a completely different understanding of the product (completely reversed workflows, missing features).I would understand if, at the initial planning meeting, we reworked the scope of the project based on time and labor requirements, but after presenting my designs, everyone agrees to what is in the document, and then I later find that someone (usually someone who signs my paychecks) has been communicating something less-than or not-equal to the agreed upon design.How do you manage to keep everyone's understanding of the requirements consistent over time? I could just force everyone to read the entire document, but the junior engineers don't necessarily need to have a model of the entire product in their head at all times if their concern is doing a really good job on their particular component.

Avisan · Accepted Answer

This is a common challenge in product development! It sounds like you're doing a great job creating comprehensive documentation, but there's a breakdown in communication somewhere.
Here are a few ideas:
Visual aids: Consider using diagrams, flowcharts, or prototypes to complement your written documentation. Visuals can often clarify complex information better than text. Regular check-ins: Schedule regular meetings or stand-ups to discuss the project's progress and address any questions or misunderstandings. Interactive documentation: Explore tools that allow for comments and feedback directly within the documentation. This can foster collaboration and keep everyone on the same page. Empower your team: Encourage your team to ask questions and seek clarification whenever needed. A culture of open communication is essential. Consider a design system: If your product involves multiple components, a well-defined design system can serve as a single source of truth for everyone involved. It might also be helpful to understand why the discrepancies occur. Are there specific areas where misunderstandings arise consistently? This could help pinpoint the root cause of the problem.
Keep in mind: It's impossible to eliminate misunderstandings entirely, but by implementing these strategies, you can significantly improve communication and alignment within your team.
Would you like to discuss any of these ideas further?

elawler24 · Answer

I think it largely depends on the culture of the org (maybe share stage, eng vs sales led, what kind of product). It sounds to me like you don't have buy-in from engineering or they're not engaged with your process. What if you asked them to write up a technical spec as a first pass? Then you're both including them in the process and putting the ownership on them to figure it out. I usually view designs / specs as a first prototype, and then you iterate from there.

physicsguy · Answer

> then I later find that someone (usually someone who signs my paychecks) has been communicating something less-than or not-equal to the agreed upon design.Ultimately if you've got people going behind your back and directing people to do something other than what you'd like, you're going to struggle here.

nomad-nigiri · Answer

Loom videos walking through Figma prototypes >>>> any doc.Archive everything > 60 days