Everybody should go read Bullshit Jobs.
How many of you know that the team is working on something that no-one wants?
21–30 of 428 posts
Re: How many of you know that the team is working on something that no-one wants?
#22“Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.” I‘m 2 years into my first role as a product owner (made the switch from design) and working at a fortune 100. The thing th…
The bigger the project or smaller the company the more customer involvement is demanded. You may not be in that nexus. If the app runs with new features perhaps that is good enough.
Re: How many of you know that the team is working on something that no-one wants?
#23Obviously using a throwaway here. Our board members got it into their heads that successful companies must have an AI "play", so they instructed the CEO to invest about 10% of our development budget on AI. We are doing absolutely inane projects that have no hope of succeeding. We serve a niche industry where certified professionals have to do certain tasks personally, instead of being able to delegate to secretaries.…
Just pivot to "assisted-AI" where your solution is really bad but it adds "super-powers" to all their existing employees. It may give cover to some other businesses to fire staff under the "force-multiplier" argument that your software adds ("If their software makes every employee 33% better, we can fire 33% of our staff!").
And of course you're being facetious, because if everyone is 33% better, the company can fire 25% of its staff (right?).
Re: How many of you know that the team is working on something that no-one wants?
#24“Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.” I‘m 2 years into my first role as a product owner (made the switch from design) and working at a fortune 100. The thing th…
What you're missing is that the 'customer' in this case is not the buyer of the product, but rather a proxy for them found in the PM.
Big, heavy, complex products, the kind one imagines F100 companies build, are not suitable for literal agile where a paying customer as willing and able to iterate with the development team.
With that kind of product, you have many customers. When you have many customers, they always have conflicting requirements. You cannot engage in an agile process with more than (say) three of them for the same product. You'll very quickly reach an impasse and lose all of them as customers, and end up with the same product anyway. And you'll open the kimono, so to speak.
Instead the PM has to decide (based on various activities such as seeing what other companies are doing, where the space is headed, and yes, talking to customers) what the product is to look like, and he (or more likely, you the product owner in this case) has to engage with the dev team. You have to be the customer that actually needs and wants something, and that the dev team has to satisfy. This is why PMs have to have significant industry experience. Often, CEO of a small company slots into PM role in larger companies.
Agile as written, with paying customer in mind, is for consulting style engagements. But that doesn't mean it can't be applied well when PM is a stand-in for the customer. It keeps the dev team moving, and brings the 'C' players up to 'B' level. (Unfortunately it also brings the 'A' players down to 'B'.)
> Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.
yes and yes. You are being naive, and this is how most companies operate. That your boss can't explain it to you just shows that the company doesn't understand the application of agile and are just cargo culting, like most companies, and doing a very poor job of "Agile" because they don't understand it. Most companies implement agile as a way to micromanage devs, not as a way to get a better product, and even then they suck at it.
Re: How many of you know that the team is working on something that no-one wants?
#25I listening to customers is not really something you can only do with agile scrum. You can figure out what customers need with roadmaps or projects too. Outside enterprise, you also don't have one set of customer/users, you have thousands or millions them.
I agile scrum often leads to situation iterate the teams iterate towards local optimization or solving problems that people think they need, but fails to deliver actually create next level impact, since teams are hesitant to make plans longer than in two week increments.
I think most successful product teams take the practice of closely listening to the users (as the whole team or product organization), trying to understand the user, but choose to build product they think is right, even it's not what the customers currently say they want.
Re: How many of you know that the team is working on something that no-one wants?
#26This would be an interesting ask HN. I dont think theres much to discuss on the actual link since it looks like its just some sort of ad for some training program?
Re: How many of you know that the team is working on something that no-one wants?
#27“Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.” I‘m 2 years into my first role as a product owner (made the switch from design) and working at a fortune 100. The thing th…
> I’ve been told that someone in leadership described me as being too “black and white” in this area, but I consider myself both pragmatic and flexible to alternative ideas.
When I've seen responses like that in the past, it's often somebody who just doesn't want to listen to any complaints, for various reasons. I recommend a quieter approach, where you don't tell anyone what you really think about the problems, but just wait for an opportune moment to ask "can we do X for Y?" in a public forum. That way you can't be ignored, you aren't complaining at all, and somebody else can later take credit for implementing your idea, without them having to admit that they were the cause of the problem to begin with.
Re: How many of you know that the team is working on something that no-one wants?
#28Re: How many of you know that the team is working on something that no-one wants?
#29Earlier quoted context omitted.
Just pivot to "assisted-AI" where your solution is really bad but it adds "super-powers" to all their existing employees. It may give cover to some other businesses to fire staff under the "force-multiplier" argument that your software adds ("If their software makes every employee 33% better, we can fire 33% of our staff!").
And of course you're being facetious, because if everyone is 33% better, the company can fire 25% of its staff (right?).
That's hilarious - I can't help but think of this dilbert cartoon on making change:
https://dilbert.com/strip/1993-03-20
(I am not putting you down)
Re: How many of you know that the team is working on something that no-one wants?
#30> Don't just build Something™, build an industry leading product that customers want and love! The point of writing software is to get paid. If the process leads to something actually useful, good on you. If not, you still got paid. It was just a drill, life continues.
That advice is OKish if you only ever want to be a mediocre employee clocking in to get your wages.
I think you need to be far more proactive in training your mind if you want to become a founder [edit: of a successful business], or move into more responsible roles, or even just to get satisfaction from shipping great software.