Depends on the style of the company. Different companies would say different things about this.
Apple: "Bad advice. Let a "Jon Ive" type design-lead think through the product and detail every page of it. Don't let engineers run product. Give them the ability to give feedback on product, but give the ultimate authority to somebody who understands human emotion, art, UX, etc"
Google pre-Page: "Good advice. Engineers should control product. They are smarter than everybody else, and therefore will make the best software."
The reality of these company's positions is more nuanced than this, but these caricatures have their place in helping to understand how they think.
We have a "ship on the first day" policy for new employees which has been working really well - it forces the issue on getting development environments set up, keeps our deployment process quick and simple, and means that by the end of day one we have another person who is ready to ship improvements to the site.
In my experience, tasks that take longer than one week sometimes take two weeks. But if they don't make it within two, they basically never ship. It's like you can go out and have one drink, or two, or many. But never three...
That's such a great way to put it. You hit the nail on the head. For the rare exceptions to this, you better be damn sure it's worth the time, and that you really need it. Because if you think about it some more, you will probably discover you're better off not doing it at all.
I've had a few tasks like this that we just ended up scrapping, even after several weeks of work, because we found we didn't need the monstrosity of a feature as much as we thought we did.
I feel like the author sort of answers this question with the following statement:
It’s not perfect. We ship too many features, many half-baked.
The product is complex, with many blind alleys.
It sounds like his team is more focused on just getting something out and improving it iteratively than it is on producing a polished product that is architected beautifully.
This is a great approach. It's also not always appropriate for everyone.
We do regular one-day long refactoring sessions where everyone refactors. But yeah, our codebase is not a thing of beauty. We're more focused on figuring out what users actually want, and we'll rebuild it when it's falling over.
All of these things are doable, but require a combination of people and their skills that are very difficult to find. You need the following:
1) Product people that have shipped code themselves in the past and can provide enough detail for an engineer to run with.
2) Fullstack Engineers that are empowered to fill in the gaps in business analysis, process flow, and UX on the fly using their gut. They also need to have a good eye for design and shouldn't have to ask a designer to help for everything.
3) Solid instrumentation to rollout, measure, and rollback features on a live system in way which limits user impact.
4) Bulletproof trust on the team and a culture that supports being able to make mistakes and learn from them.
I feel like at a certain point you are moving too fast. The author makes it seem like he is chasing after speed at his own peril.
Isn't it better to take an extra week to polish a feature than to just "ship it" and then patch it later? At a certain point as your organization grows and your product becomes more mature shouldn't your focus shift from quantity of features released to actually shipping quality releases?
I know there is a balance here. Don't be so worried about polish that you don't ship anything but don't be so blinded by speed that you ship everything within a week. You just can't make blanket rules like this.
The problem is that there is an incentive to always pad estimates. By forcing a one-week schedule, you counterbalance that tendency, and make it possible to measure yourself more accurately. Despite this, I'd say that many of our projects fail, never ship, ship and have to be rolled back, or ship and have to be iterated 5 or more times until we get them "good enough." But it still beats taking 3 months to ship something interesting, which is the cycle most startups are on once they're out of an incubator or done with their initial release.
Probably the best way to ship "wrong". You ship, granted. But I imagine that part of the feature you push weekly are small, and so would have more meaning if part of a bigger push. You also probably end up with a lot of non-polished features, half-baked as you name it. I honestly don't see anything good point in that article, what happens to 2 months project? You cut it in 3 to 6 pieces just to have to ship? Meaning you waste time forcing yourself to push something that works rather than focusing on the end goal.
An API is still an application programming interface right? What kind of distributon / business development are we talking about here? And how can it possibly be conducted through an API?
You don't have to wine and dine Facebook's business development team to get the user actions in your app syndicated on Facebook, you just use their API to do it yourself.
WOrks for some set of development projects. Especially if you develop using libraries that have the 'hard stuff'.
But consider who wrote those libraries. They took longer than a week. They are not just a basket of features, they may be a large architectural puzzle.
The point is, the author's advice may work for a web page, and there are a lot of startups that just make a web page these days, so sure.
As long as you control the product entirely, I believe that it's possible to break tasks down into one-week chunks. But what happens when you depend on external parties to complete your task? If they don't delivery, or if it just takes a lot of pm legwork to get things moving, a technically simple task may well take many weeks to get through.
Problem with such one week shipping stufff is you are inadvently creating a mess. Everybody is concerned about shipping but everyone forgets to do the gardening and trim the weeds.
Apple: "Bad advice. Let a "Jon Ive" type design-lead think through the product and detail every page of it. Don't let engineers run product. Give them the ability to give feedback on product, but give the ultimate authority to somebody who understands human emotion, art, UX, etc"
Google pre-Page: "Good advice. Engineers should control product. They are smarter than everybody else, and therefore will make the best software."
The reality of these company's positions is more nuanced than this, but these caricatures have their place in helping to understand how they think.