The hard work, the problems you can’t solve, don’t get easier, they get familiar. We get better at solving them because we are familiar with all the constraints, context, and, constructs that surround them. Change any one of those components and the problem didn’t become harder again, it became unfamiliar. Step away from working on that problem for a few months and then go back to it, the problem itself isn’t harder, you’ve simply lost…
Imagine your team builds houses akin to how they write code. Some questions to ask; How long would it stand the test of time? What issues would appear immediately? What would work well? Would it align with what your users wanted? Would it ship completed? Would it be finished early or late? You can come up with more/less questions, the point of the exercise isn’t to take your team down a notch – the goal…
There is a narrow space between an end user and the person building the requirements where sheer Nirvana for what is being created exists. Where what the user needs is properly laid out and what the requirement writer is able to fashion into a meaningful delivery that looks to all of their additional/base requirements they have. It’s like the pot at the end of the rainbow. Or if you met Snuffleupagus. Or when two incongruent…
Have you ever asked yourself? Have you ever asked your team? Have you ever set the expectations of your team for what you expect of them and what hear what they expect of you? Until you do, you’ll never know just what your meetings are missing. But we never want to ask, it’s easier to complain.
Does it matter? If you don’t know enough can you figure it out? If you can’t figure it out, do you know who to ask? When things go sideways are you going to stop or keep pushing into it? The question isn’t how much you know, but how much desire and drive you have to learn to know.