41–50 of 62 posts
https://en.wikipedia.org/wiki/Feature_creep https://en.wikipedia.org/wiki/Scope_creep
That's not a particularly good way to encourage discussion. What is it specifically about Feature & Scope creep that you would like to say?
1. A bias to ship and a bias to ship new things are not one and the same. A lot of the problems, such as a failure to iterate on existing products/feature, sound very much a product of the later, not the former. If anything, the issue "Insufficient Iteration" is probably not correctable without a bias to shipping.
2. A bias to ship and a bias to ship things that impact your customers are not one and the same. There is a note about an early shift to micro-services. I can't speak to this organization, but, generally speaking, spending time on internal engineering work to the detriment obvious missing features is a common issue with early stage companies.
3. A bias to ship and a bias to ship to the right customers. Specifically in regard to the high value, high demand customers.
4. A bias to ship and... idk what to call this? "The product specs were well thought through, sometimes crafted for months." TBH, the problem with this one feels like a lack of a bias to ship.
As described, I think the real culprit was a lack of or poor prioritization. FWIW, I suspect the author and I may actually be in violent agreement as I did find my self nodding with most of his lessons learned. Though I'd be careful about letting too much hindsight bleed in (eg - do situations that'd be improved by more decision documentation justify the effort of documenting all product decisions, especially in the early phase when the product is rapidly evolving)?
I work at a company that grew from a few hundred to a few thousand people in a few years' time, and there was an identical mindset and identical problems over that growth period. I started during that growth period, and 10 years later, we're still digging ourselves out of those mistakes. One reason for this was how heavily we prioritized first mover advantage. We pushed extremely hard to get into new markets, and whi…
I worked at a small company that was always chasing the next potential sale. Potential customer mentions feature A and all of a sudden all development shifts towards developing that feature. The vast majority of the time the potential customer never became a customer. In the meantime competition focused on their own plan of features and our product wound up with features no one ever wanted and was missing critical fu…
Made every single day a death march and a company that survives purely on the sunk cost fallacy on the part of the investors. They've already dropped $MILLIONS into building this thing, and the CEO swears that this next big deal will be what finally pushes the company into the stratosphere. As miserable as it was to work there, I'm honestly impressed they're able to keep that zombie moving.
This article is in that direction. > … the difficulties started piling up fast, and before we knew it we had to deal with a lot.
Earlier quoted context omitted.
Could there be a hybrid approach? Have teams that focus on being a first mover and shipping and then once there's a product on the market, you have a secondary team focusing on fixing the tech debt early while the other team continues to iterate
At my old company we had an innovation consultant come in and tell us that kind of approach was nearly impossible to manage in the longer term. Apparently teams dedicated to holding the fort grew bitter and had much lower retention than teams on greenfield work. Paying back the debt, he said, usually requires too much knowledge of a system to cycle teams in and out consistently enough to ensure everyone gets a piece…
This is kind of interesting but it sounds like the perpetual worry of the perfectionist developer. Of course you end up with tech tech, you develop new things when you could improve existing things, you deploy something that could be iterated but you don't. The truth is that the world is a complex place and you don't always know whether you can keep your existing customers by improving what you already have or get ne…
I'm far from being a developer perfectionist, I wouldn't spend 10 years in this company if I was one, trust me (btw we fired a lot of them along the way). The point of the article is not to convince anyone to slow down as much as possible and work on bugs/etc. It's just that at some point (3, 4 years in?) there comes a time that you just have to put more effort into the things I described, otherwise it gets complicat…
Earlier quoted context omitted.
I worked at a small company that was always chasing the next potential sale. Potential customer mentions feature A and all of a sudden all development shifts towards developing that feature. The vast majority of the time the potential customer never became a customer. In the meantime competition focused on their own plan of features and our product wound up with features no one ever wanted and was missing critical fu…
I've had the exact same experience. Throw in a large dose of "no repeat customers" due to us prioritizing Feature A for Potential Customer B over fixing existing gaps that affected actual customers, and it was a never-ending parade of haphazardly created, bug-riddled new features that never got improved. Made every single day a death march and a company that survives purely on the sunk cost fallacy on the part of the…
Like: don't just add weird features that make sense for just one customer, but are eventually delivered to all customers, but instead maintain a "core product" which provides a lot of generic, core functionality, but which by itself isn't actually usable and just serves as basic building blocks to construct the actual end products which are then built and packaged individually for each (big) customer. Each of these "end products" is a development project in itself, has its own team, its own codebase, but they all draw from a core set of base functionality developed and maintained by another dedicated team that is not directly in contact with any of the customers (or at least not permanently).
This - at least in theory - prevents custom functionality for specific customers from polluting the common core product that aims to please a general audience, while still allowing for the necessary freedom to satisfy big customers demanding custom functionality, but also offering big checks in return.
I always wonder why nobody appears to try a hybrid model between product and project development when it comes to satisfying large customers which need very specific customizations that often don't fit well into a product development roadmap aiming at satisfying a more generic audience. Like: don't just add weird features that make sense for just one customer, but are eventually delivered to all customers, but instea…