This is one of those rare articles that points to the need of good Product Managers.
As a PM I’ve seen my fair share of “PMs are useless waste of space”.
The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.
The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.
The most dysfunctional engineering organizations I have seen are ones where product managers are embedded at the deepest levels of the team and do everything from defining requirements and handling cross team collaboration all the way to planning and running sprints, bug triage and release management.
On the other hand, the effective ones have always had way fewer product managers with a lot more individual authority, who are in charge of the overall product direction but will let the rest of the team execute it to completion.
Product managers are really business managers. Their goal is to ensure the software meets a business need that can help the firm developing it translate the value it delivers into $ by application of a commercial model.
Put another way - they define the WHAT and WHY, the HOW should be managed by their colleagues in Engineering.
The best PMs I knew were amazing analists. They wrote logs quiery processing code themselves to understand the product better instead of asking other engineers to do it. The only problem with them is that they don't stick around, but start their own startups.
I keep ending up in that kind of a role. But since I’m higher paid than project managers I always get forced into doing development instead. So either I have to do my actual job after hours so I can help the company out. Or just do what I’m told and ignore the big picture.
Would be nice to do it in a formal way about taking a massive pay cut
The thing is he wasn’t forced into a role of writing code. He was an APM at Google when Google didn’t have many PMs, and he was in a supporting role of helping teams to be organized and decide on the future of the product when we didn’t know whether some non-technical ideas should be executed upon or not and help with the non-technical part of the execution.
Nowdays I felt just the opposite happening when I worked in Google Ads: PMs getting new feature requests from sales people and pushing down on us with strict timelines, even if we feel that that feature is not the best way to deliver better ads targeting for our customers.
Probably you should just go to a smaller company with less PMs, where the PM/Eng ratio is optimal or too small (or go into higher management)
I've done this and it fail horribly, I'm the product manager as well as the implementor.
The problem is usually I choose solution which is easiest to implement and usually the scope is too tight because I need to also design the lower api and libraries.
I too feel like i've learned through experience that the product manager (whether with that title or just effectively being the one doing it) should never be the same person as the implementer/tech lead. It just doesn't work. And as an implementer/engineer, it ends up being so much less stressful when there is a product owner who you collaborate well with, but who is someone else. And you get a much more succesful product too.
Even though I think I am someone who understands the customer/domain pretty well, and is good at empathizing with the user, you're just too close to the implementation to effectively product manage.
In the domain I work in, I think people are used to the "head implementer" being the effective product manger (although without that title), and it takes some work to try to convince decision-makers, please, let's not do that.
Microsoft does this and IMO is one of the reasons their products are lackluster at times. There are other reasons but this is definitely one of them. The PM role is spread so thin they don’t have enough time to boil down seemingly related pain points or customer rants in to a coherent story. Even with perfect execution the product tends to have a broken UX.
My take is that a good Product manager is worth their weight in any ridiculously rare metal you care to name. They will act as a force multiplier for the dev team.
But a bad product manager will poison the well, make bad products and be out of sympathy with the code and tech.
And as it is very hard to tell the difference, well why not play it safe?
It’s not hard to tell the difference. It just either takes a while, or you have to spend a few months without a PM.
I had a PM leave on me at my last job. It took 3 months to get a new PM. That meant all the PM work fell on devs for a while. Believe me, I could tell that both my old PM and the new one were good PMs after that experience.
> My take is that a good Product manager is worth their weight
A good X is worth their weight. Sure, any good professional is always welcome, but in regular team in a regular company, regular PMs are mostly dead weight (in contrast, regular devs are just good-enough devs).
Absolutely 100%. As a senior dev, I’m fairly decent at considering actual customer problems, business need, and the product roadmap for the near future. Start talking about the market as a whole, cultural shifts, and all that jazz, and I’m in very deep and probably reduced to treading water. I suppose that makes me an okay-ish ersatz PM, which has been good enough for me thus far. Unfortunately, the career path of a dev doesn’t seem to reward going very deep into PM type stuff, so I’m probably going to progress fairly slowly on that axis. :/
If you enjoy that part of the business you can always just apply for a PM/PO role. Thing is, it's a really hard job, and most people don't enjoy being the business whipping boy. Much of my job is saying no to things which have demonstrable value, because there are many other things which have demonstrably higher value. Said stakeholders see the world through their departmental lens, and expanding their vision takes a lot of effort. Often it doesn't work at all. This makes me the bad guy.
On the flip side, I've worn many hats and it feels like one of the most impactful places to be in a business. I get to shape what we build, and see it to completion. Very satisfying, but not easy.
Well PMs who used to be devs like you end up being very effective in my experience. They really ‘get it’. Add in high agency and you get a very potent person the team can rally behind.
PMs are important, but for many projects it's not a full time job (having a PM that can write out things to build doesn't directly mean there's enough people to build those things). In some orgs this leads the PMs to take on a half marketing role; that can end badly if this leads to the PM chasing whatever thing their latest customer / prospect interaction mentioned, rather than sticking to plans for long enough to get things to stabilize. Additionally, some times they can end up promising features and fixes on a schedule that isn't sustainable for engineering (but that largely depends on how the organization manages the work; this may not be in scope for a PM, in which case they're shouldn't be promising any sort of timelines).
I think this is ideal, but in my experience PMs are given the responsibility of building Gantt charts and managing swim lanes, instead of articulating requirements or verifying requirements have been met. Thus attracting people who want to manage resources instead of requirements. I then end up taking on requirements as part of the building it process... which to be honest works well at least on smaller builds.
I've always felt that having the dev experience helps. As you're walking through requirements with a client you're also piecing together how it should work.
PM’s are their own worst enemy. Only a couple I’ve worked with aren’t a waste of space. Sometimes that’s due to the problem space not needing a PM but often PMs earn their poor reputation.
Having discovered that it's easier to be self-effacing, the quick way to the top is just to directly contact the sociopaths (who usually just say "yes" to everything).
As for requirements specifically, I believe that to make it easy, they should all be 0 or ∞, which makes it easy to test. In practice, laws of physics will add other limitations, but having a grasp of those will make it easier to articulate the design decision (e.g. we can't make that faster because it's already at the speed of light).
Imo, the trouble starts with the term "requirements."
There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.
The requirements problem is like that.
Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.
Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.
Part of this is a separation of concerns between people in different roles. The person designing the thing may be different than the person engineering particular parts or getting parts in the supply chain.
Take something like a radio. The person building the electronics to meet the design and sourcing the parts may need to know the requirements around the temperature it needs to operate in. The person handling the internal electronics is very likely different from the person designing the product. The person designing the product will need to know where, when, and how it's used by whom.
With software we often mash the roles into one or a few people. A developer may do all or many of the parts. If we look at other engineering disciplines, aside from software engineering, requirements often make sense.
I was just reminded of someone who had to test PVC piping. It had to meet certain standards for handling pressure. The people do engineered the materials, the thickness of the pipe, and so forth had to know the requirements it needed to meet. They also needed to know the requirements for the size of the pipe so that it would mate with other things. They weren't designing the system the pipes would be used in.
Requirements are often a way to take the design, break it up, and communicate it to others who aren't part of the design. They are also a way to create common interfaces. Both of these are things software designs are often bad at. Sometimes intentionally so (non-standard interfaces create lock-in).
This problem comes from the absolutist implication of the word. A better word is "Objectives". Objectives aren't created equal like calling them "requirements" implies. Requirements must all be completely fulfilled for the request to be satisfied, while Objectives are ranked by importance and can tug against each other. Having contradictory requirements is a semantics error, but having contradictory objectives is normal: that's why they're prioritized.
"Make me a billion dollars" may be your objective, and while it may not be an actionable one, it is in fact important to distinguish in your design whether your primary objective is to make money, rather than being a passion project for example. The cost-benefit analysis of various design decisions changes depending on how big a priority profit is.
You may be willing to make decisions that are less profitable, but lead to a better product, when profit isn't your primary objective.
Whatever you call them, attempting to formalise them as a discrete object is flawed.
These aren't discrete objects. They're key parts of a formal, or semi formal decision making process, administration systems, management methods and suchlike.
Look... there are outlining methodologies that playwrights or novelists sometimes use. It's fine to use such constructs. What's not fine is trying to build institutions based on them.
It's just not reducible neatly into profit objectives and such. Those are fine tools, but they're not good models of the world.
At my organization we call it "requirements mining" -- because getting good requirements from which you can build useful software is f*cking hard work.
I really like "mining" here. At least for me the connotations fit really well. I think it's better than "inventing", because it's not like requirements come from thin air. They exist in a raw form buried in the stakeholder's minds / domain knowledge and they are extracted to a useable form through hard labor.
Inventions don't come out of thin air either. They interact with context, needs. They arise within limitations. Etc.
I totally disagree. The spec dies not exist. It isn't buried in your customers' brain or your CEO's. It isn't mined. It is invented, one way or another, by those making the damned thing.
The "requirement" for a spaceship is "must travel to the moon." What software requirement mining tries to do is mine Kennedy's mind for the design of the bathroom.
The requirements and the spec are very different things. The requirements are exactly the thing that comes from the stakeholders. The spec is a way longer document that must match the requirements, but it is not the requirements.
Also, the requirements for a spaceship are only "must travel to the moon" if your customer is a 5 year old child. The real list of requirements is way longer and includes things like "must be compatible with our existing launch infrastructure".
While it's true that requirements come from the stakeholders, often the stakeholders don't really have them, they don't know them, and when they think they know them, often those are not the "real requirements" but some proxies which may even need to be violated to get a good product - i.e. I may think that a significant requirement is to ensure that some thingamajig very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig at all.
The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.
"The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do or not do."
> Imo, the trouble starts with the term "requirements."
> There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.
> The requirements problem is like that.
Yeah. Someone, in the history of SW had a great idea: requirements must be atomic.
That's why a lot of products break when they are put together.
> Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.
They are gathered. They are however, not a collection. They depend on each other. And when this depenfence is missing or left over the engineer will invent it to compensate for the lack of it. Every engineer. In its own way.
> Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.
If everyone has slosh in their expectations budget, its ok, but if people want some undefinable thing and they know it when they see it and they get mad when they don't get it, you're going to get engineers asking for the "perfect spec" - because that's what they are effectively held accountable to.
> a collection of requirements adds up to a design.
No it can't A collection of requirements implies many, many possible designs.
Change the team, you get a different design.
A good-quality requirement is _testable_, amongst other things. After the design and construction are complete(-ish), the team should have to show that each requirement is in fact met by comprehensive testing.
Along the way, each requirement should be mapped to elements of the design. So you can (on paper) verify the design meets requirements. And the designer(s) can be confident they are meeting the full set of requirements.
And for the nay-sayers that complain you can't ever adequately elicit the requirements out of the users (or customers), then your engineering process needs to address this risk. See many comments that refer to ways and means to achieve this mitigation.
Good leadership identifies issues or opportunities in markets, builds something useful, and most importantly, markets and sells into the domain.
Having worked on both sides, I would say that understanding markets and being able to sell into them makes almost Engineering seem pedantic.
This 'gathering requirements for Engineers' is an 'engineering centric' way of viewing things. I mean you have to take some perspective on it, but I think that the issues is going to revolve around 'the hard part'.
If you're building new Nuclear tech, the Eng. is going to be a 'hard part'.
Otherwise, it's the money, markets and selling that is 'the hard par' and the Devs. are bit more like Construction workers but with more thought in the process.
Requirements from a "committee" of stakeholders are indeed gathered to turn design by committee into reality.
Software requirements encompasses a vast spectrum of best practices and creative problem solving, mediation and imposition, linguistics and invention, details and principles, according to the people and domains involved.
We spend an inordinate amount of time learning about deep technical issues and there are many training courses along those lines--many of them very good. Does anyone know of boutique training services who train devs how to mine requirements and run dual duty as a dev and emergency PM?
A team with a strong product leader who is visionary and empathizes with users will run circles around a loosely organized group of stakeholders/engineers duct taped together by process. The problem is that it is hard to scale.
This has been my experience, along with most great product leaders I’ve known have been “promoted” from developers/engineering as opposed to from the business end. Most devs/engineers I know also don’t want to take on this responsibility because they would rather be developing rather than overseeing product development.
I would love this role and have had the chance to act in it. I'm quite adept at it but I do not want to be thrown into a business or domain that I don't know. It's like asking me to invest in a company or industry that I'm not an expert at. I need to be a a dev that just crushes stories for a while so that I can observe and learn about the business. I can sense the fear and imposter syndrome in people who have never been a dev and who don't really know the business. They are dead weight, and nobody wants to be dead weight.
I'm not so sure that agriculture has successfully scaled across the human axis. We've successfully scaled agriculture only by removing much of the human element. Even very large farms, in terms of production, employ relatively few people. At that small scale of human involvement there still is often a lot of struggle with the people.
The goal here is to scale things to what is needed and in a way that is feasible, i doubt solar panels would've been feasible as a scaling method for energy during that time, much less electric cars, or even less likely, farming strategies and equipment that are ecologically less 'problematic'.
not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
If the answer is no, then it is , like i said, irrelevant.
> The goal here is to scale things to what is needed and in a way that is feasible
I beg to differ. As far as I know we scale up things in order to benefit from economies of scale. And we do so because the 'technical system' underlying our civilization leads us to always want 'more'. J. Ellul, among others, wrote about this.
> i doubt solar panels would've been feasible as a scaling method for energy during that time, much less electric cars, or even less likely, farming strategies and equipment that are ecologically less 'problematic'.
Indeed.
Note: some of those ways (solar panel/electric cars/farming strategies/...) have flaws (bad side-effects), some of them catastrophic, we aren't aware of, but will discover (just as all fossil fuels, which enabled the Industrial Revolution, do have catastrophic side-effects.
> not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
Claiming that those effects were beneficial is acceptable. However it IMHO doesn't balance the bad side-effects (current climatic challenge). Saving (or enhancing the life) of some doesn't justify creating a major risk for others (later).
> talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
The case may be about obtaining anything (even a population) 'big' without economies of scale (or, to put it bluntly, without a technical system), I doubt so, and our ability when it comes to detect bad future side-effects of selected solutions (IMHO this ability is near zero). That's the reason why I think that what works for humans (and maybe for each and every complex life form) is a society built upon small groups, and more generically that everything that (in our society) works for long and without any major blunder is done by and for such groups. In more than a way L. Kohr showed it.
> Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
I would, indeed.
> If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
At the time: no, however knowing what I know now I would plead for a very (VERY!) progressive (time and space) implementation (precautionary approach).
> If the answer is no, then it is , like i said, irrelevant.
I understand your point, mine sits on the "let's avoid committing the same error twice" principle.
I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem.
Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.
Depends what you’re trying to build. Sure, if you’re just doing consulting work then go get requirements from a customer and deliver on them.
If you’re building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
> You need to understand problems to solve and turn those into requirements for a product
One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do
For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters?
Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets
Even when you get requirements beware that the customer doesn't know what they want. So you get asked to make a faster horse instead of invent the car.
Just because someone can pay for a requirement doesn't mean that requirement adds value to a product. If I think the cost for a requirement is higher than its value - which may potentially even be negative - I'm going to present my case for stripping it out.
The most difficult thing is a culture insisting on passing the buck as not their responsibility.
I find there are 2 extremes of developers:
1) Ones that develop very fast (and does not think about what is being developed, sometimes blindly). There is no reward to speak up to ambiguities in requirements, or even mistakes. So the mindset here is "can be fixed", "QA" will find, etc.
2) Ones that develop much slower, overly reviewing requirements, use cases, etc., and spending more time with product / designer throughout development.
________
For those who are team leads, managers, hiring managers, which of 2 above would you prefer?
________
EDIT: I am not a super star coder (more a "jack of all trades"), but I have very good intuition on product so many times I wonder if there is a better job field for me. I would be interested to hear ideas along this path.
> So the mindset here is "can be fixed", "QA" will find, etc.
There's an alternative mindset here as well: let's get something in front of the users because they don't know what they want (because they gave us vague requirements), and this lets us iterate more accurately.
This is a strategy if you have developers with certain freedoms like talking to users directly vs. having product owners to distill requirements, and more or less running the entire development lifecycle.
IME the "get it done" devs are not interested in following up with customers or looking at metrics to see how things are performing. They're on to the next task that they think will get them the promotion.
This definitely depends. I'm at a startup and I'm close enough to the business that having features DOES matter, so releasing them has material value. There are metrics to follow, but there are also individual customers asking for stuff too.
I think it's bigger companies where this mentality starts to become pervasive with promos.
You give Coder 1 projects and in a week they have a working version that starts generating revenue, albeit with cut corners and limited scope. After it bakes for a month or two and we are sure we want to keep this thing, you hand it to Coder 2 to improve quality, integrate with the rest of the stack, etc.
If it was a bad idea you throw it away and C2 never needs to support it.
C1’s fast velocity is largely a product of the high quality codebase curated by C2. C2 is always spending their time on known-profitable projects, thanks to C1. We also make sure C1 and C2 are both involved in deciding what we build and in deciding architecture.
Usually C1 is a more business-motivated type who is excited about the domain. C2 is usually more of a technical purist who is excited about building great software.
On a team with good leadership this is a very powerful combination, everyone is valuable.
This is weird to me in a thread about requirements gathering. The OP isn't making the case weighing good, but slow, programmers and bad, but fast, programmers. They're specifically calling out C2 moving slowly to gather requirements and talk with the product/design team. Which is very likely NOT a "technical purist" type, since I doubt the technical purists are the kind to give two shits about the domain (I'm one of them, even though I realize caring about the domain is now my job as Lead, doesn't mean I have to like it).
If C1 delivers quickly on bad requirements, there is no guarantee that product will make revenue. Ask any startup founder who started building a product before doing market research and validation.
I think when we add the archetypes of "fast but sloppy" and "slow but clean", we end up with more permutations than C1 and C2 since the matrix looks more like:
[ Business Oriented, Technology Oriented
Quick/Sloppy , Slow/Clean ]
C1 isn't for fast-but-low-quality. It's for instances where you have a detailed spec. Maybe there isn't much ambiguity. Maybe there is, but you're working with an iterative process or something where building the wrong thing right is ok.
In my experience though, there's a never enough C1 type of work to go around. C2 is always the bottleneck. Requirements, specs, stories or whatnot do not reliably make good sense at the point where someone is actually making thee thing.
So to OP's question, I'd take the C2. Not because you don't need C1s, because you probably already have enough.
I used to work in a place where (1) was called as "Customer Engineering" and (2) as "Product/Standard Engineering" (i was part of this group). The former allows you to hook in the customer and keep him engaged with quick feature deliverables in separate code branches some of which are then rolled into the "master" branch (with due diligence like refactoring, making it robust and more general etc.) after due consultations with Marketing/Sales.
I was a skeptic initially, thinking (1) would be producing crap code which would need extensive rewrite but that didn't happen in reality. They were experienced developers themselves (this is the key for (1) ) and so the code was mostly okay and needed little tweaking. Everything worked surprisingly well.
I believe every Company needs to have these two groups in Engineering.
> The agile boys use user stories to capture requirements. A user story is a statement in the format “As some user I want to do some action so that some reason”.
This isn't, strictly speaking, true. There is nothing in Agile that requires you write "User Stories" at all, let alone this specific style of user story (the "as a _ I want _ so that _" style is called the Connextra template, and it was created as an experiment, not a doctrine).
Alistair Cockburn calls stories, "promissory notes for future conversation." That's it. They can be one word, they can be a sentence. If you're writing anything down in your story, it's to remind yourself of the conversation you had with your team, not to create a contract where you meet the requirements.
If you can't have a conversation with the team, and the team doesn't include a person who has skills to engage with the customer regularly, then yeah, you shouldn't be attempting Agile. Saying "User Stories don't work for teams who can't talk to the customer" is like saying, "A bicycle can't work without both wheels." Duh.
One of the four things, so one full quarter, of the Agile Manifesto is, "Customer collaboration over contract negotiation." [0]
If you need a contract, you should probably rethink something. Either you're not really trying to be agile, or you don't really need a contract, or something very rare and not-normally-your-process is happening.
Honestly, this is probably another case of confusing Scrum with Agile. They are not the same. The author claims to not have much experience with "Rapid Prototyping" (the concept not the tools), and in that sense I would humbly argue that the author, therefore, does not have much experience working on an "actually" agile team.
[0] - https://agilemanifesto.org/ I always feel bad quoting sections of the Agile Manifesto, as I think it's so short it should be read in full every time it's relevant, but it's hard to slip into a comment like this without derailing the remaining part of the message entirely. Please do give it a read, even if you've read it before.
The "Agile Manifesto" is nothing other than commonsense platitudes elevated to (unbecoming) Insight. There is nothing concrete and actionable in it. The "Rhetorical Devices" engaged by its proponents are (from [0]);
Okay? Agile got referenced in the article in a way that was not accurate. I made an attempt at correcting the misconception. If you have a beef with Agile, that’s fine, it’s just nonsensical to try and bring it up here.
>One of the four things, so one full quarter, of the Agile Manifesto is, "Customer collaboration over contract negotiation." ... I would humbly argue that the author, therefore, does not have much experience working on an "actually" agile team. ... I always feel bad quoting sections of the Agile Manifesto, as I think it's so short it should be read in full every time it's relevant, but it's hard to slip into a comment like this without derailing the remaining part of the message entirely. Please do give it a read, even if you've read it before.
My response was to your above statements. As is evident, almost everyone of Meyer's criticisms are proven True here.
Everything you quoted is couched in the stated assumption that one wants to be Agile already.
If you don’t want to be Agile, then don’t. I don’t care. However, if you’re trying to follow Agile principles, there are right ways, and there are less right ways.
It looks like you just want to argue. That’s great, it’s just not for me.
>However, if you’re trying to follow Agile principles, there are right ways, and there are less right ways.
What is this even supposed to mean? To me it seems like (6) indulged in by Agile proponents. At best the "Agile Manifesto" is a exhortation to cultivate a particular "mindset" but there is no Process nor Methodology defined anywhere. Hence there can be no "right" way; everything is made up each of which can be interpreted in many different ways.
My point is to expose the "hollowness" of Agile/Scrum/whatever.
I mean, I've been taught that the number of development cycles was what the Waterfall / Agile spectrum was about... with an upfront contract without any prototyping being as Waterfall as it gets.
I have been working as a DWH developer for a few years but I retained the role of sole requirements taker for the whole company.
IMO there are two difficulties I found to be particularly hard to break through. One is for business users to clearly state their requirements once and for all. The other is for me to fully understand what's going on on the developer's side.
Solving the first one is easier for me because eventually everyone agrees that requirements can be staged. With enough experience in BA I kinda anticipate each stage and make sure that the later stages do not conflict with earlier stages.
Solving the second one is a lot harder because I have to learn a lot of programming buzzwords. I need to understand micro services and read service charts. I also need to know how the app uses the services. Overall it's a tough job.
Fortunately I can arrange meeting with developers so that we would go through each one and make sure the current architecture supports it. It's a lot of extra meetings but it's a hell lot better than extra fire fight meetings.
Interesting, being from the technical side, I feel the opposite. It is easy to see the long term technical implications of a requirement, but hard to figure out what the users actually want.
I sort of figured this was an inherent problem. Users won't know what they want until they get to try something, I figured. Interesting and surprising to see that someone else, with a different background, has little trouble with the users
You've both explained why the job is so hard, and hard to fill: a competent PM/PO must speak both "business" and "tech" fluently, without being experts in either. In my long years I've found some people speak business very well, and they're promoted. Some people speak tech very well, and they're promoted. To find someone who speaks both languages well and wants to spend their lives translating between two camps which often times don't even want to understand the other side is demanding and difficult. We often end up taking all the heat with misunderstandings, requirement conflicts, capacity constraints, and priorities. Such a candidate is usually earning as much or more in their respective camps, with comparatively lower levels of stress.
I guess it depends on the background. I came from BA so I implicitly know everything the business wants(and still have to break them into phases).
I completely agree with the second paragraph. Sometimes users have no idea what the real data looks like so have to wait. But there are other cases when they see additional data that can be useful if a bit of new data is added, which results in ad hoc requirements.
About 1 year ago I changed the way we find requirements. This was after reading about non-violent communication. The basic premise is: find out what people need. Not what people want.
Most of the time users will come and say what they want. They basically describe what their "perfect" implementation should look like. But almost never do they describe what needs they have. Or what they really wanna solve with that suggested implementation.
Now we always ask: What's your need?
They can suggest possible solutions/implementation. But that's only a suggestion.
One extra benefit when asking about needs is, the person who implements that feature can better empathize with the user.
As a supplement for anyone who is unfamiliar with the communication side of things:
In our highly solution-focused (and -driven) societies it is hard to actually see much less adequately express underlying needs[0] to yourself and especially other people.
For example I'm very adept at leapfroging over all that 'chit-chat' about observations, feelings, emotions, needs and getting right to the juicy 'objective' of possible solutions, often at the dire expense of my actual needs and making me even more deaf to the needs of the other people involved.
Well, surprisingly a lot of tenacious conflicts aren't characterized by a lack of a set of solutions quite the opposite, they get stuck because of the unwillingness (of both parties) in considering to change one's 'strategies' in order to fulfill the underlying often unexpressed needs (as defined above).
At an impasse there are usually two disregarded meta-strageties at play in order to force a quick 'solution':
(1) My set of strategies had brought me success otherwise I wouldn't be in my advantageous position X so I will continue using them, no matter what.
(2) (At some point) I will say "yes" and ignore (some of) my needs in an attempt to appease.
As it is clear both (desperate) attempts are self-defeating (in the long term).
Several jobs ago, I was given a requirements document with a number of sentences highlighted as specific requirements. I was asked to copy each highlighted requirement to a list, briefly outline each one and estimate the development workload for each one.
I did all of that and sent the report with estimates back to my manager, who responded that I had missed an estimate for one item out. That item was "Code will be of good quality". I responded that all of the code will be of good quality and it would be nonsensical to estimate an amount of time to this one thing as it if was a separate task.
"I'm not not going to write a complete system with bad code and then spend time re-writing it to make it good code."
That's a good example of something the article mentioned, which is that people from different disciplines (and, I'll add, people in different job roles) use the same terms differently.
To a software developer, "requirement" has a special meaning. It describes how the software will behave. To most other people, "requirement" is just a regular word with its everyday meaning. It describes something that can't not happen. That something can be anything, not necessarily limited to software features.
(They probably should be able to figure out from context what a software developer is really asking for, though. And one of these things is not like the others.)
It could perhaps be a requirement if there are associated acceptance criteria. Once we know how 'good quality' is measured, it can be written to meet said 'requirement'. It may not be a useful requirement though.
I spent the last 6 months being "one week away" from finally receiving the requirements for what essentially boiled down to a multi page form wizard. Maybe 30 meetings total.
They ended up just saying "go get started and we will get you requirements later" to which I said "no thanks" in so many words.
I've happily been relocated to another team. I'm excited to hear how many months /years it ends up taking them to hash out what could probably be knocked out in a single well organized sit down.
Many times (I'd say most times) it's much easier to analyze a problem after creating a solution for it.
Sometimes creating a wireframe of the UI is enough, sometimes the visual component is not that important, sometimes a PoC is needed.
That's what it sounds you were asked to do, be part of the analysis of the problem and the search for the right requirements. Through code instead of some other tool, but so what?
That's part of the developer's job (the more interesting part of the job, for me). Anybody can implement a perfectly spec'd out form. Maybe even an AI.
Nope, I was specifically not allowed to. I'm not a UI person, and they hired a UI person.
I offered to take control of the whole requirements gathering and wireframe process up front and was turned down because they had already hired the CTOs friend to come in as a consultant
It's unlikely he was expected or even invited to these meetings. Business stakeholders are often outright hostile to anyone else being part of the requirements gathering process. However, to your point, it sounds like he should have interjected anyway. I have had to force my way into broken feedback loops to shut them down many times. This is one important skill in the PM/PO role: facilitating meaningful requirements gathering and collation - especially when they don't want to play nice.
Then they are going to fail. At the bare minimum you need to have at least one person working both on the technical side and directly with the users, otherwise the risk of making something they didn't want nor needed grows exponentially.
Communication is difficult, but isn't the hardest thing, just another in a long list of difficult things.
And requirements aren't hard because of communication, requirements are hard because they are mostly unknown to everyone involved. While there are "little r" requirements in projects, if I encounter a group/firm/company/culture that puts a capital "R" on the word, I try to stay away. Creating software is largely finding something worth creating, and a process that puts Requirements in the foreground has an implicit assumption that Waterfall actually works.
The essay starts off on the wrong foot and doesn't really go anywhere that hasn't been trodden in countless other articles. Even worse, it ends with "no/low code tools will save us!"
I've found that wireframing dispels many issues with ambiguous requirements - my team usually goes about it by first having an open ended conversation about what we want to achieve, with both engineers who are not part of the target industry and a team stakeholder who is; then try to come up with a list of requirements like the list of shalls the author describes; and then if it's a visual task at all, make a wireframe describing the functionality, which we first review internally and then review with customers who will use the product. We find that Whimsical is a pretty nice tool for doing this, as it is a nice level of "low res" enough to not stress about the details, but "high res" enough to be able to imagine the real deal.
After some cycles of iteration we're usually pretty well aligned about what we're building, and only then do we start coding. Engineering teams sometimes go too fast to punching out code when figuring out requirements could save enormous amount of time, effort, and stress.
I’ve looked at many wireframes as a backend engineer, and I agree with you 100%. They’re an invaluable tool when they’re available. Now, if only there was a meaningful way to wireframe a data pipeline, then I’d be good to go. ;)
There are times I feel that "there are no real requirements" is the most accurate description. At least, not in the form that developers can actually start to craft a quality running system from. It's all requirements theater; there is nothing specific about it and it's impossible to achieve a linear mapping from high level thought bubbles down to an if branch or error check.
Really; a lot of what I work on day to day can be summarized as 'this thing over there needs to be better, or maybe pink'.
Can't give up though; I'd encourage the author to follow their instincts towards prototyping tools. The quicker you have a running system the user can 'feel' (as the author puts it), the closer you are to a shippable outcome.
And yeah PM's are useless wastes of space, but I'm glad they are there to help the rest of us ineffectually get the next Frankenstein up and limping.
> And yeah PM's are useless wastes of space, but I'm glad they are there to help the rest of us ineffectually get the next Frankenstein up and limping.
I have worked in several positions where there was no project manager.
Doing so massively improved my appreciation for them.
A bad one can be miserable, for sure.
A good one is worth their weight in platinum, though. They drive figuring out user needs vs wants, they prioritize the ever-growing pile of work, and handle any communication that doesn't require developers so the devs can stay focused on the problem of writing the software.
This article is great but missing the best solution to requirements capture: being a user. When you are a user of your own product it sidesteps miscommunication, misunderstanding and the 1000 little decisions you make every day while you code mostly end up going in the right direction.
Every time I work on something I try to learn to think like the user, at least a bit. I even had to learn the basics of coal mining once. You could say it was a waste of time for a programmer to learn coal mining. But, it Saved countless hours of misunderstanding and wasted time.
Second best option is when your product owner is a user.
Then all the other approaches are even last place. Imperfect solutions to a problem id rather not have.
It should read "communication". The hardest think about engineering is communication.
Requirements is a communication problem.
You can help your engineering by making sure ideas are correctly named, that definitions stay true to principles and the same throughout the company.
When software is built on immutable principles then it hardly ever needs to change because principles do not change (or they are not principles).
I have worked developing various banking systems. Most of the time it is not requirements that change, it is people discovering they have different definition of something that other people have and the change is to accommodate differences in understanding.
Requirements analysis changes as you move from B2B to B2C and to CC
(what I call consumer communism)
As a young engineer working on bigger institutional projects we
followed the classic waterfall processes, fact-finding, system
analysis, separating out functional and non-functional, stakeholder
mediation and so on. Stuff mainly worked and we had gruntled clients.
Although things took many years, and ran over budget, but not too
much.
Getting into smartphone related startups after 2000 I saw a wholly
different culture. It wasn't just the Agile thinking, but the
movement to mobile always-on tech made almost everything part of the
maintenance phase. Companies no longer even try to ship finished
products. Anything can be added or changed after the product is in the
"consumers" (not customers) hands. Time to market and sheer speed of
development has changed the requirements landscape.
After 2015 I noticed a far more disturbing shift. Requirements are not
even part of the picture. The customer will "have what they are given
and like it". Why?
As we know, for many ventures the profitable part of business is not
giving value to the customer but extracting value _from_ them to sell
to other businesses. The product is merely a vehicle for foisting
features upon users who are made a captive audience via lock-in,
legislation that mandates products or complexity that hides function.
In this "hostile technology world" any requirements come from parent
companies or partners in the rent extraction game, or are dreamed up
internally. The job of marketing is to push/sell these features as
"necessary and inevitable" and of customer/public relations (if it
exists) to deflect disgruntled consumers or assuage their fears and
disappointments with empty assurances.
Reading this feels like fast-forwarding over someone's career as they mature in their understanding of problem-solving for others.
Good intuition with rapid prototyping, as it encompasses the necessary steps of understanding the problem, finding the appropriate solution and presenting it to the stakeholders, all in a relatively low-cost package.
This. I like to say that customers don't have requirements, they have problems they need solved (I hate the buzzword "solutions"). They're non-technical so they don't know what is possible or reasonable. It is up to the PM or lead to propose ways to solve those problems. Another issue is that (this appeared on HN recently) you can't tell people anything, so it's often necessary to show them something before they can really get on board with it. At that point things start to change and people will claim the requirements are changing, when in fact they are just starting to get fleshed-out.
There is a second layer of requirements which are essentially a design. Not design by a designer but an internal software design. The customer doesn't care about this level of requirement but people tend to confuse the two. Some developers ask for too much detail and some customers try to micromanage. It's the PMs job to manage this boundary.
Requirements are easy, people are not. It's great talking about user stories and use cases and rapid prototyping - but how do you know you have the RIGHT use cases and user stories...?
What follows is one way to get requierments right -
¹ Current State
Assess the situation. Understand the transformation (one or more processes) the client seeks to address, and find out what the technology landscape looks like. Start identifying stakeholders, and familiarise yourself with the client's worldview, environment, and the power and political landscape.
² Objective
Identify who the client is, and define the client's objective. The objective is specific, measurable, agreed to by the client,realistic, and time-boxed. It is guided by the results of the situational analysis.
³ Scope
Bound the solution by outlining it's features and functions, by defining what's out of scope, and by discussing the criteria by which success is measured. The scope delineates what stakeholders expect the project to deliver.
It's not hard but it's not going to fall into your lap without a little effort.
This is true, but it’s not a new concept, at all. Steve McConnell wrote about this, a quarter-century ago, in Software Quality at Top Speed[0].
Also, I’ve found that, even if you do a great job of gathering requirements, no one likes it, when you give them exactly what they asked for. I’ve taken to using what I call “Evolutionary Design”[1]; where the entire design “morphs,” during development.
Wouldn't engineering encompass the communication and expectations? When you design a skyscraper, you need to know what sorts of loads is expected on each floor, any height restrictions in the area (are there airplanes around?), etc. When you design a literal engine, you need to know if you're optimizing for weight or power or raw RPMs.
Perhaps you're using the word "engineering" as a synonym of "implementation" (which could work); I'd have thought it was more "design" though (in a technical sense, though I'm sure it might cover some of the aesthetic sense too).
Yes agreed. Assuming software engineering context here, not civil or mechanical or other mature industries which usually require millions to create, validate, test and release a new product.
Negotiation of requirements is a problem based on limitations like recources (money, people), known knows and known unknowns.
Ah yeah, I tend to not think of what we do (or at least, what I do professionally) in the software field as engineering for that reason. What we do seems closer conceptually to carpentry rather than engineering. Not that changing things to be more engineering is necessarily better, of course; much of the benefits of software _is_ the flexibility.
Isn't that a narrow interpretation of engineering? Especially because in software engineering you often have micro decisions that are unspecified, where user preference does matter.
Good engineering requires making the correct decisions in those cases. It requires knowing the 'actual' problem so you are not building a solution for the wrong thing. That means requirements are a part of engineering. Maybe not the full responsibility of gathering requirements, but understanding requirements, clarifying requirements, and feeding back what requirements are feasible or conflicting seem very much a part of engineering.
The issue with requirements are that they are constantly being discovered, adjusted, added-to and changed. The issue with a requirements process is that there too often simply isn’t one. Just recording them in a Feature List (sorry meant “Backlog”) isn’t such a process.
Perhaps that suits todays predominant development methodology… “hack it, deliver, repeat”. The modern “agile”.
I find few concerned about “requirements”. After all it seems that the only problems in computing are “technical” ones.
I think one of the major benefits of an agile-like process is that, in theory, so long as things don't sit in the backlog/icebox for months, all your requirements are short-lived. The “hack it, deliver, repeat” process actually benefits the requirements gathering process because you only need short-term requirements; you don't need to understand what the product needs to do a long way out because there's an implicit understanding that whatever the product is in the future will be changed to meet future requirements.
The really important thing about requirements in an agile process is that you need a set of documents that accurately describe what the product is supposed to be doing right now. Using the stories doesn't work because you have to look through everything from the beginning to build up a picture of what a feature is, and using the code doesn't work in case someone has mis-understood the requirements. Managing the change through the project is the hard bit.
That's because the business doesn't define their system (business system, not technical system). Any large business should have documented business process maps/flows with procedures for what is to be done at each step. It really amazes me at how many large companies just fly by the seat of their pants with virtually no idea of what they're actually doing, no documentation, and little ability to explain their actions.
The majority of software engineers on Earth are working on problems that are known-solvable. If you're working on novel battery charging algorithms for Lithium batteries you are in the minority -- most people are working on time tracking tools, financial system API calls, etc.
In those domains, success doesn't come from succeeding at the task, success comes from the task having been the right task to have done.
In 12 years working in the US I’ve never worked in a situation where the stakeholders get to set requirements like that; it’s always been us, the engineers, designing and implementing and deciding what needs designing. I suppose I’ve been lucky not to have had to deal with the more traditional model; my impression is it’s more common in Europe and away from SV-influenced US tech companies.
Requirements (engineering) is the discipline that crosses the chasm between reality (needs/usage) and virtuality (software/development). Add the multitude of parties involved, and the lost-in-translation stuff.
Hence, it's the most difficult thing. But noone ever points at it in schools or textbooks
People who talk about requirements "gathering" often fail to talk about requirements "changing" continuously. At my last job this was endemic, every VP and above wanted to be seen as contributing, so things changed on a daily basis in arbitrary ways, making development a minefield of eternal changes. Even waterfall would have been easier (where nothing is allowed to change), despite us doing "scrum" change was not tied to sprints but the hour hands of a clock. We still shipped things, but everything took forever and the end result was often a user unfriendly mess that cost way too much money and left everyone frazzled. Having requirements at the start of a project that rarely changed was a pipe dream.
I also once worked at a place where a large project had a ship date before the requirements document ship date. Of course when it was done it did not match what was written down, and also wound up not matching the (internal) customers needs either, so it had to started over.
This waterfall myth has to go. Waterfall does not mean "requirements never change." Waterfall includes iteration. People continue to cast about flourishes of disdain toward both waterfall and agile...trapping us all in hell. Waterfall is not bad!! Learn about it.
Product Manager in financial software here - communicating ideas is definitely hard. I try to bring a visual / diagram when discussing user stories because it takes esoteric and intangible concepts and makes them a bit more concrete.
Have to have, nice to have, and cannot have are the hardest things to get exactly right with just about any human endeavor. Engineering is especially tough because the line between have to have and cannot have often is very thin.
'Requirements' is business language and has nothing to do with engineering. If you work for a startup or big tech company there is probably already a product road map in place and people should know what to build already. It's usually not the job of an engineer to gather these requirements.
~15 years before, we had Business Analysts (BAs), who were canonically in charge of what we were building. They will own and be accountable for what's being built. They verify and sign-off whether what was built meets expectations. Part of their job entails writing detailed specifications, but not only that.
When "Agile" happened, the BA role slowly transitioned to Product Manager (PM). For a short while, PMs from BA background still took ownership and care for the board, still took care of acceptance criteria for stories/tasks, still signed off on the deliverables.
Now, Product Management has become a cult of personas. The role doesn't feel obliged to be accountable for defining specifications, or having a work handover, or signing off, or coordination, or product documentation, or anything. The role assumes it's creative work on a blank canvas. But guess what, all modern roles are largely creative, but it doesn't mean everyone should have no working model. But for some reason, this role has gone beyond beyond a working model into "I'm special".
I'm seeing many other comments below still focusing purely on the personality aspect of it. Good product managers vs Bad product managers. NO! This is about Good product management vs Bad product management. The role should have a working model and clear cut responsibilities. And those practices shouldn't be undercut by saying "I'm special". But most PMs feel "boxed in" by any way of working. They prefer calling it "culture", because culture can be something abstract and disassociated from.
We should realize: The transition to Agile has good and ugly sides. The ugly side is the broken transition from BAs to PMs, and the lack of accountability for what's being built which has left teams and deliverables ambiguous and dangling.
---
As a side addendum: I would partly blame Steve Jobs for it. For some weird reason, he has become a role model for PMs. He was a freaking CEO who did the selling and investment, you can't delegate anything to a CEO! He would have had armies of PMs dealing with the working model and details. But unfortunately, PMs seem to fetish the master salesman and personality cult angle of Steve Jobs, spending all the time in "Why", but forget about the details and start delegating their actual responsibilities to everyone else in the team. It should be made pretty clear that PMs are not CEOs like Steve Jobs. They are regular people who should have regular working models.
As a PM I’ve seen my fair share of “PMs are useless waste of space”.
The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.
The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.