Zawiłości numerów modeli, pochodzenia i rodowodu podtrzymują istnienie kuszącej pornografii, która fetyszyzuje okulary słoneczne i wieczne pióra, buty i rowery, i niemal wszystko, co można sprzedawać, zbierać, klasyfikować, organizować, a reszcie objąć w posiadanie i mieć.

Źródło:  s.7, Język rzeczy. W jaki sposób przedmioty nas uwodzą?, Deyan Sudjic

In the end, it really came down to one incredibly genius idea: Dropbox limited its feature set on purpose. It had one folder and that folder always synced without any issues — it was magic. Syncplicity could sync every folder on your computer until you hit our quota. (..) Our company had too many features and this created confusion amongst our customer base. This in turn led to enough customer support issues that we couldn’t innovate on the product, we were too busy fixing things.

After I left Syncplicity, I ran into the CEO of Dropbox and asked him my burning question: “Why don’t you support multi-folder synchronization?” His answer was classic Dropbox. They built multi-folder support early on and did limited beta testing with it, but they couldn’t get the UI right. It confused people and created too many questions. It was too hard for the average consumer to setup. So it got shelved.

If you’re starting a new company, the best thing you can do is keep your feature set small and focused. Do one thing as best as you possibly can. Your users will beg and beg for more functionality. They will tell you their problems and ask you to fix it. My philosophy is that they’re right if their feature request is right only if it works for 80% of your customers.

Źródło: Why is Dropbox more popular than other tools with similar functionality? – Quora, Isaac Haal, co-founder of Syncplicity (bezpośredniej konkurencji Dropboksa)

(..) the product development process at Amazon is centered on the customer.  Amazon follows a process called “Working Backwards”, which means that the first deliverables created are the documents at  launch, then work backwards towards the items closer to the implementation. Defining a product this way adds clarity and simplicity — you know at the front-end what the customer can expect, and working backwards allows the team to build it.  Here are the general steps followed in this process:

1. Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists – what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.
2. Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
3. Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
4. Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.

Źródło, Amazon Product Development Process: Start with Customer Work Backwards, inspiracja: tebe