Hacker News Reader

Comment by sidlls | Hacker News Reader

This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize the release of features for the sake of releasing features as opposed to for supporting the business' needs (as determined by data--including analysis of the performance of features, market conditions, and other factors).

This article describes the last company I worked for very well: that company was and is struggling precisely because the senior leadership promoted a culture of feature releases without consideration for their impact and consistently changing the focus of feature development not based on data, but whim, so that the product was steadily losing focus and coherence.

View on HN

Exactly. Feature factories build features based on random assumptions, and not based on actual data.

I just wrote about this yesterday (https://teamsuccess.io/hdd). I work as a consultant with lots of Scrum teams, and many devs feel like they're just sitting in the factory, cranking out features. Without knowing whether they're adding real value to the end-user.

So what can you do to break free from the feature factory? Something that I recommend for the teams I work with, and noticed that actually works, is "Hypothesis-Driven Development".

In short, replace the items in your product backlog with experiments rather than user stories. Instead of starting with a user story or epic, start with a testable hypothesis. Then run small experiments that will prove or disprove that hypothesis.

My favorite question nowadays is "Wait, why are we building this feature again?" :)

In my experience people are afraid to ask that question. The answer to that question may lead to questions around total addressable market which could cause uppermanagement to question the viability of the product or at least the cost / benefit of having a big development and product management team in the first place.

This is a terribly sad comment on the structure of our society, people worried they might be making something pointless. And the solution is to make sure the people paying for it don't realize.

Afraid with good reason. I think it's more likely that it would be seen as disrespectful to managment, product, bizdev, etc. who asked for it. That it's challenging their judgement.

What were the circumstances that people were afraid like that? For example, was this an in-house development team, or hired consultants? And how did you find out that people were afraid to ask these questions?

A big change we incorporated is working more closely with the data analysis team. It helped us create analytics that were more useful for them, and helped us answer some good user centric questions, like which features were used most, why were others not used, how long were they taking to load, etc...

I like this idea. Instead of:

"Add keyboard shortcuts",

The Todo item could be:

"Will keyboard shortcuts save time for the end users and result in [positive reviews from power users] that mention the shortcuts?"

Then, one sees that actually implementing the shortcuts is just one step among many.

> It's disparaging conditions that prioritize the release of features for the sake of releasing features

Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.

> as determined by data--including analysis of the performance of features, market conditions, and other factors

What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards.

On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.

Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?

Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time.

The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing.

You can make the hamster wheel spin really fast and persuade yourself you're really going places.

Until the wheel falls off.

I have no data to back this up but I'd say the majority of projects I've worked on during my career my time would have been better spent working on things that made the development teams more efficient. That is to say, with rare exception, I don't think the software actually generated anywhere near the benefit it cost to develop and maintain.

Describes a company I was at very well too. Focus on timelines and delivering some defined scope. Most of the symptoms in the article were present.

Is this just a natural course for startups unless conscious effort is put in to counteract it? I mean in the earlier days of startups just delivering features and catering to customer asks might be a good thing.

Reply on news.ycombinator.com