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 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.
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.
> 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
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 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'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.
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.
> 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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)
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).
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.
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.
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'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. ;)
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.
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.
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 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.
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.
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.
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.
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.
~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.
157 comments
[ 3.3 ms ] story [ 226 ms ] threadSomeone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.
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.
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.
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
> The problem is that it is hard to scale.
This is true for everything involving human beings.
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.
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.
You may start with the first but the second seems kind of inevitable after some years.
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.
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
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.
I'm working with one of those tools, it's free, check it out:
https://uidrafter.com
The 3D character model and some of its animation were done by Giorgos Chronopoulos (https://taloscreative.co.uk) in 2009.
The audio is a royalty free track.
For the screen-casts I used `ffmpeg` https://github.com/uxtely/screencast
The rest of the video I did it in Maya (3D portions) and Final Cut Pro (Sound FX and 2D animations).
Maybe Trump uses it inappropriately outside of titles, I haven’t paid enough attention to his writing. But the author here doesn’t.
How low is the bar for submission to this place? I can say X, immediately followed by NOT X and it'll still end up on front page, huh?
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]);
1) Unverifiable claims
2) Proof by anecdote
3) Slander by association
4) Intimidation
5) All-or-nothing
6) Cover-your-behind
[0] - https://learning.acm.org/techtalks/agile and Also see Bertrand Meyer's book Agile!: The Good, the Hype and the Ugly.
My response was to your above statements. As is evident, almost everyone of Meyer's criticisms are proven True here.
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.
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 write my notes on stickies and litter them throughout my desk area according to importance. Some people keep notebooks, you do you.
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.
Software or hardware engineering is a solution. You can solve the same with a pen and paper if you know what the user needs.
Agile is a way to iteratively validate expectations and revisit and update things with minimal wastage
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.
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).
Negotiation of requirements is a problem based on limitations like recources (money, people), known knows and known unknowns.
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.
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.
I’ve seen that a few times in my consulting days. I’d consider it a giant red flag now.
One of them even had it written into their contract, something like “developers should spend as little time as possible with the business“.
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
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.
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?
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.
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).
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.
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.
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.
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.
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.
Would be nice to do it in a formal way about taking a massive pay cut
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)
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
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).
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.
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.
Which I 100% agree with. But it’s not just for engineering, it’s for everyone..
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.
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.
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.
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.
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.
¹ https://www.wittenburg.co.uk/Work/Transformation.aspx
² https://www.wittenburg.co.uk/Work/Objectives.aspx
³ https://www.wittenburg.co.uk/Work/Scope.aspx
(Being nice helps too - people like helping nice people -- https://www.wittenburg.co.uk/Work/Trust.aspx)
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.
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.
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.
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.
[0] https://stevemcconnell.com/articles/software-quality-at-top-...
[1] https://littlegreenviper.com/miscellany/evolutionary-design-...
Building the right thing - that's the real challenge :-)
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.