Iterative development: the secret to great product launches • Hacker News Board

Re: Iterative development: the secret to great product launches

#61

Post by rangersanger » Mon, Feb 25, 2019, 6:19 PM UTC

tachyonbeam wrote: post #45

nadam wrote: post #30

Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…

> You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc I don't think that's true at all. You absolutely can and should build an MVP of all these things. You certainly could release an MVP search engine (or even a browser-based game). You probably can't hope to gain traction at large with an MVP browser or operating system, but you can start using the…

Completely agree with this. Previously I was a PM at a rather large (valued >1bn) sales software organization. I was tasked with building a completely new product to replace the original product. We built an MVP and had our internal sales team use it. It wasn't easy, it took some motivation to get them to use it over the large, steady, enterprise solution they were used to. But, they used it enough that we received considerable feedback that we rolled into the public beta, which was much bigger than an MVP.

Re: Iterative development: the secret to great product launches

#62

Post by Gpetrium » Mon, Feb 25, 2019, 6:30 PM UTC

lbacaj wrote: post #27

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…

Iterative development, Agile, Design Thinking, DevOps are all areas that require some form of culture change to teams & sometimes company. It is possible to create small teams that are driven by some or all of the items listed above, however, they usually need to be insulated from the rest by management. Will there be spillover on both sides? Very likely, but the idea is to get the wheel moving forward.

The process of moving a medium-large businesses towards a more 'Agile' mindset for example, can be dreadfully slow with plenty of roadblocks throughout the process and that can cause some executives to want to go back to their previous ways.

Realistically speaking, some companies are better-off starting to implement some areas of the items listed above and in steps, add the other areas that are relevant to the success of the company. Not all areas of Design Thinking for example, will be applicable to all segments of the company, understanding which ones to add, when and the costs/benefits of not having the other areas is really what drives success

Re: Iterative development: the secret to great product launches

#63

Post by Gpetrium » Mon, Feb 25, 2019, 6:39 PM UTC

bigpicture wrote: post #26

The longer I work in this industry, the more I am coming to believe that waterfall is nothing more than a strawman set up to make development process X look like the Holy Grail. Has anyone seen it in real life - in the pure form? I once worked at a place that "did waterfall", but a diagram of the process would have shown arrows in all directions (would we call these things salmon runs or something?) and if you needed…

Companies and employees need to be able to sell the idea of a project/product/service to each other. The waterfall method serves as a bridge that connects the dots, allowing both sides to understand how they intend to reach the end goal.

The same way you haven't seen waterfall in its pure form, you will likely never see Agile, Design Thinking, etc in its pure form. That is because we are looking at environments prone to change and in control of humans with variable degrees of knowledge and prone to change.

What you have seen with the diagram that shows arrows in all direction is simple, it went against your perceived view or the standard and that put you off. Or, the person just didn't know how what they were doing (the more likely scenario).

Re: Iterative development: the secret to great product launches

#64

Post by npollock » Mon, Feb 25, 2019, 7:15 PM UTC

Another under-appreciated fact: at iteration 1 you have very little data from feedback, at iteration 10 you've hopefully got a lot more - an iterative style of product development gets easier and more efficient as time/iterations increase

Re: Iterative development: the secret to great product launches

#65

Post by eikenberry » Mon, Feb 25, 2019, 7:18 PM UTC

bigpicture wrote: post #26

The longer I work in this industry, the more I am coming to believe that waterfall is nothing more than a strawman set up to make development process X look like the Holy Grail. Has anyone seen it in real life - in the pure form? I once worked at a place that "did waterfall", but a diagram of the process would have shown arrows in all directions (would we call these things salmon runs or something?) and if you needed…

Back in the 90s and early 2000s every company I had any experience with used some waterfall-like development model. The usual case had a 6-9 month release cycle, up-front requirements and some level of technical specification of the required work. No one did automated testing (testing was QA's job) and releases were painful. I'm guessing you just didn't start in the industry until after this practice was already dead.

Re: Iterative development: the secret to great product launches

#66

Post by thanatropism » Mon, Feb 25, 2019, 7:39 PM UTC

oldboyFX wrote: post #60

andy_ppp wrote: post #16

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resour…

Speaking from first hand experience, it is possible to build efficiently without detailed specifications. The key is to put boundaries between different parts of the application and allow each developer to take full responsibility for delivering their part. I've had some horrific experiences where multiple developers worked on the same features (without specs) while stepping on each others toes.

Ha. This depends on developers being able to stand each other during the MVP slog. I've seen launches derailed because nerd #3 didn't like to be told how to do something by nerd #5.

Technical talent is a the-odds-are-good-but-the-goods-are-odd kind of deal - at least outside Silly Valley in the developing world. You can hire a huge sum-total-IQ but you can't hire people who can work independently and collaborate.

Re: Iterative development: the secret to great product launches

#67

Post by rladd » Mon, Feb 25, 2019, 7:50 PM UTC

lbacaj wrote: post #27

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…

Your sentence rendering is very impressive and lifelike. Great job!

One suggestion: pause a bit more after the end of paragraphs, particularly after long paragraphs. It can help comprehension.

Re: Iterative development: the secret to great product launches

#68

Post by hellohellohihi » Mon, Feb 25, 2019, 8:38 PM UTC

rladd wrote: post #67

lbacaj wrote: post #27

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…

Your sentence rendering is very impressive and lifelike. Great job! One suggestion: pause a bit more after the end of paragraphs, particularly after long paragraphs. It can help comprehension.

+1 on the sentence rendering. I've been looking for a tool like this for quite some time and was pleasantly surprised by the quality!

At some point down the road, it'd be nice to have the ability to adjust playback speed.

Re: Iterative development: the secret to great product launches

#69

Post by Celarnor » Mon, Feb 25, 2019, 9:47 PM UTC

dschuetz wrote: post #13

I don't understand why Risk Management isn't a thing anymore. Reducing risk at cost of reducing quality of a product is not generating a "great product". It's great for reducing risk for investment. So, the "secret" lies beneath the actual product - quicker return of investment. That's what agile actually means now. Great.

Did it ever mean something else? :P

Re: Iterative development: the secret to great product launches

#70

Post by avinium » Mon, Feb 25, 2019, 10:08 PM UTC

andy_ppp wrote: post #16

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resour…

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built.

It depends.

With certain projects, the overriding risk is that you're building something that nobody wants. In this case, Agile makes a lot of sense, and specifications are a waste of time until you've validated customer demand.

For other projects, you're very confident that demand exists for the product you're building, and specifications start to make a lot of sense.

Big caveat though - you can get this assessment very very wrong. "Demand" can be a very open-ended concept (e.g. in the entertainment industry), but that doesn't necessarily translate to user satisfaction. No Man's Sky, for example, probably should have been put in front of players a lot earlier. That means building to a looser spec in shorter cycles with more iteration (more "Agile", for want of a better term).

This is why product managers are so important - they need to make this judgment. It's a difficult balancing act to juggle "minimum features and user testing", "grand product vision" and "efficient and manageable development cycles".