Presenting your requirements to Stakeholders

[NatalieSmith]

How detailed or scoped out are your requirements before you present out to stakeholders? Does it depend on company size and culture?

When I was at a mid stage startup I shared requirements with all stakeholders at the very beginning but at larger company it seems like a unspoken rule is that you have to have requirements much more developed as compared at smaller companies (anecdotal observation)

[MarcoSilva]

How much the org believes in agile tends to determine how detailed they want requirements. The more agile, the less detail because they know the product development process means uncovering a lot of those details along the way.

[ChristieDook]

Well with the stakeholders you should be presenting their goal to assure you understand what they want to achieve but they should not define them too deep because you need to allow your team the ability to discover. The team will tell you how they can achieve the ask but the stakeholder should just see the goal.

[DhirajMehta]

Hey man, as a PM you need to communicate a lot in a limited amount of text. You need to have a different language for a CEO, Sales, and tech. So your communication varies accordingly, here are a few tips that could help -

1. Always keep it short and to the point for tech
2. Keep it shorter and metric-relevant for the CEO
3. Keep it a little descriptive for Sales. Discuss with them very clearly

Again these are a few things I’ve learned so far as my stint as a PM is concerned. But I think more than organizations, it depends on the people you’re interacting with - so yeah keep that in check.

[NaomiNwosu]

Kind of a one size fit all question answer… but I’d say your reqs gotta match the feature adequately and accurately.

I work in a 40k employee company with most in operations. My requirements aren’t always the most fleshed out, but it really depends on the feature/product enhancement. I’ve presented to 20ish attendees with high level requirements (accurate but without in-depth detail) and it was adequate for that audience (execs). I’ve also been grilled hard over super small and unimpactful features (tech debt) … Probably to make sure I’m actually putting effort into my job lol

But if you’re ever in doubt, more details are better than less. You never know whose hands your doc will end up in! I can 100% say that senior leadership doesn’t doubt my work anymore because of it!

[AngelaBlue]

@NaomiNwosu, Basically all of this usually I don’t have the most detailed reqs… on paper. But I sure as hell know the in’s and outs of them before I present. Usually my reqs are high level but then I have enough knowledge to go into detail if needed.

[RobMartin]

I like your answer but some nuance on “more details are better than less”: it depends on the audience. The worst received requirements I’ve presented are when someone feels like I’m doing their job. Designers sensitive about mocks, devs about architecture, execs about prioritization (mvp vs v1 vs v2…). I’ve found presenting fewer details but explicitly stating who will be looked to solve a defined problem can be more helpful at the early stages.

[pouyataaghol]

@RobMartin, Why are your execs deciding how you scope your releases? Or am I misreading what you’re saying?

[RobMartin]

@PouyaTaaghol, You are not! At some places they don’t: and so I make the call (but invite feedback). At others, the political reality is that some people need to feel in charge and giving them a lever, versus being argued against, is just less hassle and builds buyin.

Ime, b2b startups with insecure leaders fall into the second camp.

[pouyataaghol]

@RobMartin, I’ve definitely been at a startup like that (and then thankfully the CEO got moved to the board and I didn’t have to deal with that anymore haha). I was just curious if that was your environment too, or if there was another reason for it.

[EvaRichardson]

There are likely dependencies on company size and culture, but really it depends more - I believe - on roles, experience, and category. I’m not sure it’s wholly useful to break this down by size, or even culture. It depends more on the “who” and “what” of what you’re building.

TL;DR

The usual unsatisfying answer: “It Depends” Or… “everything’s a situation”

Super Long Version:

Examples are probably easiest here:

• Minimal Requirements: If you’re at a smaller company, (and this would be part of size thing to some degree), and everyone is basically ‘all in’ on the product, and it’s a relatively simple product, then playing ‘pictionary’ at the white board is maybe good enough, plus a couple of well written stories. (Of course, it’s always the case that even with just two people, what was said and what was understood may be different.)
• Medium Requirements: Now let’s say you’re at a company that may be small, medium or massive… and everyone has advanced degrees in User Experience, they’re all expert programmers, etc. But… some of the key stakeholders are customers and they need to be deeply engaged because you’re doing lean, and you want to be design-sprinty, etc. etc. Here, these externals may be subject matter experts in their space, but not very digital beyond their social media profiles. Here, even a paper prototype might not get you the feedback you need. Maybe you need something at least Figma/Zeppline/Invision level at reasonable fidelity to get what you need. And such a thing ends up being a somewhat detailed artifact for the User Story/Stories or Epics around it. I call this medium, because it still maybe doesn’t take terribly long to get done.
• Deep Requirements: You’re working on a mission critical app that has real world IoT or IoMT (Medical things), involved. Yeah, there’s the whole lean MVP concept and you can be all agilista, blah blah. But here… going too MINIMAL is probably not VIABLE. Or perhaps I should say it as, that which is VIABLE just isn’t all that minimal. Maybe you could hurt or kill people if you screw up the medical device software. Or the flight management software. Or the industrial controller software. You’re going to have real world friction in supply chains, multiple suppliers, lots of interdependencies, etc. etc. And maybe you’re using some external development shops as well. True agile might work with higher trust levels for external providers, but that’s not a project anymore, that’s just staff augmentation. To bid scoped project and on a Request for Proposal with potential Statements of Work (SOWs), you have to have some reasonably deep level of requirements to start. At least, Business Requirements. And likely at least some degree of functional requirements. (You can do things without this level of detail, but then you better have a huge budget and practically blank checkbook; and how many get that?)
• Crazy Deep: Your mission is so critical I can smell it from here. Consider: The Voyager 1 spacecraft was launched over 40 years ago. It’s left the solar system. Its Operating System is still going. If you needed someone to hit Ctrl-Alt-Del on something on board the spacecraft, getting there would be somewhat challenging. It was never designed for this level of robustness, but… still. And if you’re sending people? You’d better go pretty deep. SpaceX/Elon is kind of sticking with somewhat Agile in that they’re philosophy is to just fly. And sometimes stuff will blow up. And it is. At amazing cost. So the question here becomes where do you want to take your pain? The theory of Agile, (or one anyway), is you’re less likely to miss the market due to changing conditions if you adapt as you go vs. some big waterfall style requirements first, which might take months by which time things have changed, etc. etc. But if your risk is super high, and you might only get one or two chances, it might make more sense the old-fashioned way.

My answer has been horribly long. But I just found the others unsatisfying. As with most things’ product management, there’s not always a clear template for a somewhat fuzzy question like this. Yes, there are many templates and frameworks, but the thing is, knowing where to apply which one is always going to depend on a collection of factors. And understanding the information needs of the stakeholders is key. But it’s not going to be just about size/culture.

[PriyaVarma]

I work with clients, so I have to get sign-off on requirements, but it’s a bit of an art to find the right level of detail. Too much and you’re boxed in, not enough and the requirements are not helpful for the team. I don’t include anything about design unless the client specifies somethings unusual. This is really what an experienced product manager brings to the table - being able to read the team and the situation.

[KaranTrivedi]

Size of organization is certainly a factor, how “lean” your organization is, but also your industry. Some industries require much larger capital expenditures so an idea that isn’t flushed out will be difficult to get buy in.

[MichaelYoffe]

I find simplicity is the answer 98% of the time. I tend to figure out where the feature could be in 5 years, design a few versions/systems that could be ultimately flexible for at least 3 long-term goals, then streamline it over 3-5 sessions to truly understand the most flexible MVP… Ideally, I have 3-5 very simple pics and less than 100 words before I start getting upper-level and front-line feedback. I use that feedback to trim it down further, then try to express the whole concept in 3-4 pics and less than 50 words for an executive pitch.

Once I get buy-in, I start adding in more details, trimming those down, adding in more, trimming down more. Overall, my team wants an MVP that’s also a long-term solution for multiple pain points, and they want minimum viable specs (I truly make sure I have not wasted a single word) that consider any gotchas.

That’s worked great at large and small companies for me…elegant solutions communicated with simplicity, buy-in is easier because they can immediately feel out the scope of the work and see it’s multi-purpose use.

When I derail from simplicity, it’s a bit of a mess because I’m an extremely detailed planner and give way too much detail.