6 ms·

The four dangerous animals of product development

• ThePadawan 6y ago
  The marketing speak is tragically hilarious. > Having a clearly defined prioritization process can help ensure all your team members understand how decisions are made and give them the confidence to actively participate. "The boss said we have to do X" is a clearly defined prioritization process. Now go tell your team members that's how decisions are made (note the passive voice) and tell them to get on it already ("give them the confidence to actively participate").
  • nine_k 6y ago
    That's the definition of the previous animal in the list: the boss says so, others don't need to bother themselves discussing. This is a valid way to make decisions, but it does away with any upsides of discussing things or basing decisions on data. Another problem is when a team of the "big guys" actually discusses stuff, and someone co-opted into the discussion does not feel like adding a word, "nobody will listen anyway". That person could be e.g. a subject matter expert and potentially offer valuable, decision-changing input, if made to participate. It takes a conscious effort to make such people feel welcome and share their opinion — which was the very reason to invite them to a meeting.
  • ochronus 6y ago
    Thank you for the feedback! I agree, I failed to elaborate on this, this is definitely not what I meant. Now I extended that section a bit and added that having "The boss said we have to do X" is exactly what leads to having a team of disillusioned RHINOs.
• PaulHoule 6y ago
  He uses RHINO twice, so if this article is going to be memorable it is going to be for the mistakes.
  • karmakaze 6y ago
    Yeah, It's too bad it went with initialisms instead of memorable animal characteristics. A couple work both ways: Hippo throwing their weight around, Wolf doing their own thing.
  • vikramkr 6y ago
    Yeah. - I dont know what that was supposed to accomplish. Its not like the author didn't have enough animal namespace left...
• birdyrooster 6y ago
  Is this article designed to create imposter syndrome? What was actionable about any of this?
• stephc_int13 6y ago
  "Push for a data-driven culture." Yep, stopped giving any credence to this article after this line. In practice, data-driven is extremely hard. Most A/B testing is blindness dressed in nice clothes. Data-driven is only cost-effective at some (large) scale, because you'll need actual experts and infrastructure.
  • jaclaz 6y ago
    >Most A/B testing is blindness dressed in nice clothes. ... and harassing you. Excellent definition.
    • ochronus 6y ago
      A/B testing is but one way of gathering data. Also, it usually comes after the decision to actually invest in building _something_ out (even if it's only a prototype/MVP). There are other types of data such as sizing the opportunity based on market research, competitor analysis or simply asking your customers - among many other. This shouldn't be trusted blindly either, sure. Never said that.
  • nautilus12 6y ago
    Agree, it's just mumbo jumbo to most people. Being really data driven in many realms falls into the category of Complicated or Chaos (in terms of the Cynefin framework) so often times being truly scientifically data driven is a matter of a PhD thesis. The only true recourse many companies have is intuition and trial and error which according to Cynefin is the most effective means of operating in the chaos realm
  • cpufry 6y ago
    my xp at big software corps has been that technical decisions are often heavily data driven. product decisions are rarely so. i think about how there will deep dive root cause analysis for technical misses, but there is nothing like that for product misses.
    • alonmower 6y ago
• xwdv 6y ago
  At times I have been a WOLF and a ZEBRA. I would probably consider myself a fairly dangerous but effective developer.
  • ochronus 6y ago
    You touch upon two great points that I failed to point out: 1. These are behaviors in certain situation, not necessarily personality traits 2. I should have been explicit about that the article is not (only) about developers. In fact I've mostly seen these behaviors from product managers and VPs.
• baby 6y ago
  Reading the phoenix project atm. Highly recommend.
• hodgesrm 6y ago
  There may be dangerous animals of product development but they don't look like the header image. That's the cutest otter picture I've ever seen.
• longerthoughts 6y ago
  This is needlessly adversarial. Thinking about your colleagues as assailants and parasites certainly doesn’t help your product development process. Alternative titles include: “Why everybody sucks but you” “How to point out problems and suggest vague, empty solutions” “We asked GPT-3 to write an inane thought leadership piece”
  • baxtr 6y ago
    That was exactly my thought as well. Why do we need to start polarizing the workplace now too?
  • icedchai 6y ago
    Maybe so, but it's still funny and there's definitely truth to it. I recognize all of these animals.
  • ochronus 6y ago
    Thanks for the feedback, I didn't see it that way and it was never my intention - I added now a short intro paragraph which hopefully eases this tension.
• kainer 6y ago
  Guess it comes from this: https://www.productboard.com/wp-content/uploads/2020/09/The-Essential-Guide-to-Prioritization.pdf https://www.productboard.com/wp-content/uploads/2020/09/The-... Which has a lot more detail to it
  • jnxx 6y ago
    Yeah, maybe it should cite sources. Also, the title of that page makes it clear that the topic is prioritization, which, funnily, gives a lot more focus to the text.
• jnxx 6y ago
  This tongue-in-cheek acronym is hilarious: > WOLF – Working On the Latest Fire A long time ago, I was briefly involved with an organization in which management of software projects worked like this: * Lots of projects were started and promised to stakeholders. Money was, most of the time, not really an issue because of the organizations size and various kinds of cash-flow. * Marketing was always over-promising stuff which could be done. Lots of bingo words. Huge weight on design and leaflets. * The organization was a matrix organization with, like, 100 people serving 30 or 40 projects. Developers were regularly pressed or shanghaied to take on more projects (the more senior developers had perhaps twenty or thirty projects they were participating in) which of course took focus off the running projects. * Starting one's participation happened usually by sending people an electronic invitation in some kind of kick-off meeting in which they were more or less expected to participate, and telling them about their work package. It was considered inappropriate, almost rude, to say no. There would be no documentation or task defined in writing. People would meet a few times to vaguely discuss how things were going (using some kind of agile task chart), and point out dead-lines, but with nothing really concrete about the technical stuff. * The idea was, I believe, that with so many people doing so many projects, it would help enormously if people joined and gathered knowledge from different projects in a synergy effect. One was always allowed to ask more experienced people for help. This happened mainly by submitting support tickets into a big bug-tracking system. Each ticket was assigned to a team working on the topic. * The main idea to cope with all the projects at the same time was to modularize everything as to make it re-usable for different projects. Unfortunately, there was, however, very little time to define interfaces or APIs between these components. * There was also the minor problem that it was somehow hard to retain people. One reason might have been the payment structure, or the career opportunities. There happened to be companies in the direct neighborhood which were paying substantially better. However, there were some senior die-hard staff members which were valiantly holding the flag. Unfortunately, the senior members were severely overloaded. They did not even came around to document basic processes. Unfortunately, that further increased their workload. * When working on a project, sooner or later, one would run into a couple of issues which had no obvious answer. One would file them into the ticket system. A few of them would be answered, but not all, because of the overload of the other members. Then, one would become blocked. The best thing one could do was, to work on another topic. That was heavily encouraged by the creation of more tasks and projects. Now, think in a distributed system with lots of locks and messages and procedures in some kind of spaghetti graph. Because, from a certain point, other people would depend on one's own contribution, this could have the result that the whole project dead-locked without anyone really noticing. How would people have noticed? Everyone was very busy! Usually, such a stalled project would be kicked to run again two or three months later if some deadline was approaching or some report due. * When these issues were brought up with lower managers, it was rather evident that they were aware of the problem. However, conversations about that ended all-too-often with the suggestion to pick up on a further project. So, it felt a bit like as if critical feedback up the command chain was not possible, or at least strongly undesired. * Surprisingly, the result all of these efforts did not matter that much. It was somehow good enough to keep the organization going. One reason for this was surely that software was not an important product of the organization, or at least the top managers had the view that it was not a main priority. With the distance of a few years, I am wondering if this structure was perhaps actually caused by some kind of micro-management. It was clear to me that the most developers would have hugely preferred to work on a much smaller number of projects. What would support this view is the experince how much organizations are often generally influenced by the top decision-making people. On the other hand, I've come to the conclusion that most seemingly dysfunctions in organizations, or their parts, might have deeper causes, and, in a way, good reasons, in how the organization procures resources. What happens is inevitably also an optimization of this procurement of resources and of what is perceived as important. Anyway, I'd be curious whether this kind of management pertains to some kind of pattern, and what is perhaps the best course of action one could take as a new developer in such a case. (I was pretty conflict-avoidant at that age, and I left that organization rather quickly, in spite of what could have been, at a technical level, rather interesting work).