Como você entende as necessidades das partes interessadas para suas inovações tecnológicas?

Another tool that is helpful in this process is the RACI chart: responsible, accountable, consulted, and informed. This chart can help define who your stakeholders are, ensure you have good coverage across roles, and clarify what each persons role is.

Most of us know what we want solved, but we all struggle with effectively communicating it. I learned this from a book titled Borrowing Brilliance (David Murray) - all great problems were once solutions to other problems. I learned the technique of the "problem rabbit hole" which I use to engage stakeholders in conversation to extract requirements. Essentially you design an conversation to start with a problem that needs to be solved, then ask why is that problem there, you will find that it was once a solution to a prior problem, and when you follow the problem rabbit hole you find a "root problem" (not to be confused with root cause). Finding the root problem helps increase the definition of the conversation around solving problems.

Until about five years ago I used to ask stakeholders "if we had all the resources in the world" what would you want to build? Recently I found it effective to ask the opposite question, "if we only had $250,000" what is the one thing we must build.? The question of scarcity helps me analyze the needs of the business as much as the question of abundance helps me, if not more. Hope this helps.

Nothing is better than a drawing. I loved the physical whiteboard before hybrid. Today, I use a combination of PowerPoint and drawing/writing before I go to wire framing, or prototyping. I draw a diagram in PowerPoint (this is faster and more effective to lay out the framing of things) then a take a screenshot of that diagram, and drop it into my drawing tool (there are many). I then proceed to "draw and write" over the screen shot of the "diagram" that I made in PowerPoint. The combination of these two helps me convey the gist of the requirements, turn around feedback quickly, and very inexpensively way before I engage resources to wireframe or build prototypes. Drawing, and writing, over diagrams, still works.

This is one of the more complex steps. The reason being that as new facts are uncovered (something took more resources that was estimated) there is "realignment" that is needed. So after you align on day 0, you are out of alignment by day 90. You can leverage the reality. I plan for realignment, as a part of the governance and reporting cadence, realigning the priorities, sequence, and dependencies are something we "expect to do again in 90 days". This ability to say "this is what we are agreeing on for 90 days, and we will do it again in 90 days" removes a significant amount of tension from the alignment process. It transitions the discussion and exercise from a permanent choice, to a temporary agreement. Hope this helps.

Here proactivity is superior over reactivity. I practice the discipline to "ship the version you are ashamed of" - "If you are not embarrassed by the first version of your product, you’ve launched too late." Reid Hoffman. Sending your stakeholders things as early as you can to get their reaction and feedback is a proactive way to monitor stakeholder needs. One downside, is that stakeholders might not be accustomed to seeing "unbaked" outcomes, so be sure to be super clear that this is "not close to done" but at a point where you can take an "early peek" at it and give feedback. If stakeholder expectations can be conditioned, this can work marvels for monitoring needs as they shift.

Understanding your stakeholders' needs involves more than just knowing what they want; it's also about ensuring they grasp the technological possibilities. Without the right information, stakeholders can't make informed decisions. Often, a solution can satisfy a stakeholder's requirements, but it could be enhanced if they had a clearer understanding of the available capabilities from the start. So, when you're discussing your stakeholders' needs, make sure they know what is and isn't feasible. This knowledge empowers stakeholders and instills confidence in the development process.