I work in a company where the CEO manages the product team, who mockup features and drop in the lap of developers to then implement said features. There is some iteration of course, developer's opinions are respected. But I wonder how effective this process is.

Jason Calacanis just wrote :

The Zuckerberg Doctrine: Developers design products with significantly improved speed and functionality compared to product managers and designers, outweighing potential mistakes and drawbacks.


Then it really hit me: Developer-driven startups always produce product faster.

This stands to reason: our nontechnical people are having discussions and debates while Zuckerberg is coding his next feature. This is why no one has been able to keep up with Facebook!

While MySpacers debated how to iterate on their product, Facebook simply tried stuff.

Does this actually work better in practice ?


10 Answers 10


Products should be customer-driven.

If your customers are software developers, and you use your own product (which you should, in any case), then I suppose you can be your own best customer.

But as a developer, your perspective is already compromised by what happens under the hood. You need the customer to tell you that what you are doing with the user interface or the application workflow is goofy and doesn't make any sense.

As a developer, you need to know the right questions to ask of the stakeholders so that you can combine your experience with their wants to produce the best possible product.

  • I fully agree that products should be customer-driven. For me Linux is an example how a good developer-driven product does not work in the end user market, because end user needs are not adressed.
    – Simon
    Dec 15, 2010 at 11:59
  • 1
    +1 for customer-driven, with this one quibble: even if you use your own product, you are by definition not your customer. You'll never look at your product the same way a customer does. That's why you need customer advocates and product management people who can look at it the way the customer does.
    – Dan Ray
    Dec 15, 2010 at 13:27
  • @Simon: Linux works great for lots of people as it is. It's largely designed for a different group of customers than, say, MS Windows. Dec 15, 2010 at 18:53

As a developer, I'd like to think that we do a better job than managers and designers. But I don't think you can generalize.

One of the problems with developers doing the design is that they may not be in touch with the needs of the end users, and may not be good at asking the right people the right questions. A manager, and particularly a good designer may be better at figuring this out.

However, I think the more cogent thing is not the people but how they approach they approach the problem. The approach that works is to get down and implement stuff, rather than spending endless meetings and cutting down trees to come up with the "ideal" design. It is really the Agile versus Waterfall revisited.

(It should be clear that Facebook is an example of how NOT to do things too. For instance, their cavalier approach to privacy issues is starting to get them into legal trouble ...)

  • I agree up until the last paragraph. Is it really necessary to bring privacy issues up in this question? Dec 15, 2010 at 2:00
  • @Jason - I think it is relevant. It illustrates the problems you can get into with the "getting down and implement it" approach. Gung-ho developers typically don't think about privacy. The fact that it is Zuckerburg's people is particularly ironic.
    – Stephen C
    Dec 15, 2010 at 5:37
  • @Jason I think it is relevant because it highlights a drawback of the just-do-it method is that it can sometimes get you into trouble that could have been avoided with more deliberation. It's of course a risk and a trade-off.
    – Davy8
    Dec 15, 2010 at 7:45

IMHO, I would say you are partially right. It sounds reasonable. But, this may not apply to all the products/software. So, I would put it this way. A designer should be a person with ample amount of development experience under his belt AND not just that - the person should still be coding and not not just designing.


Short answer: sometimes.

Long Answer: Customer-drive development works if you know who your customers are and they know what they want.

Developer-driven development has merit for people that don't realise they will find it useful yet. In other words, sometimes customers can't always know what they want. New Requirements can come from an existing experience of how an existing product is deficient. There weren't any customers for Facebook, Zuckerberg created a product, an answer before the question. Now established, Facebook is influenced by its customers, but before it was created and during creation, it was a developer-driven idea.

Customer driven development is ideal for established, perhaps mature product making money or new iterations of the product in the same market, where ignoring the customer's wishes would be highly detrimental to future income streams.

Developer-driven development is a sideline, prototyping activity, falling within the Google 20% arena, whereby their developers spend 20% of their working time on own projects.


To design a good product, you need a lot of knowledge about the problem domain. A general-public product like facebook can be driven by developers, because it solves a problem developers have, too: How to connect and stay in touch with friends etc. The same is even more true for products aimed at software developers: Developers know what an IDE should do and how.

But for many other problem domains, developers often just don't know enough. Even with a general insight and some experience, they will often tend to implement cool features or features that are easy to implement, but do not add much value for the customer and make the product more complex. These are cases where products should be driven by domain experts.

  • And the domain expert is sometimes the manager, sometimes the developer, sometimes the CEO, sometimes the product manager, sometimes the customer support person, and sometimes the sales person.
    – Jay Godse
    Dec 19, 2010 at 15:45
  • 1
    The bigger problem is that often people think that they are domain experts when they are not. I have seen product managers and CEOs go on about a problem that never existed in the minds of the targeted customers. Of course, these product managers and CEOs didn't spend enough time actually talking to potential customers to discover their pain points.
    – Jay Godse
    Dec 19, 2010 at 15:49

I think this is clearly the best approach to a developer-oriented product (like AWS or Visual Studio), but I'm not sure that it's clearly the better approach in general. I mean, I usually see things happening the other way around: developers stand around arguing the best approach while the non-technical people quickly make decisions. Personally, I'm inclined to say the correct answer is somewhere in the middle. There should be a product manager with the ability to set broad direction that the developers then implement.


Developer-driven software might be in most cases better than manager-driven software. Manager see the most value in features (mostly buzzwordish features) that look good on an ad or can be used in a speech. Developers see different values: performance, lesser bugs, lean design, maintainability. That leads nearly almost to better software.

But the best would be user-driven software. Users really know what they need, what helps them to do their real work. That would be the ideal.


What if you produce products faster that noone wants to use?

Focusing on a single attribute (functionality, time to market, price, qualitity, etc) can make sense for a certain point in time. E.g. Apple kind of rushed the iPhone and the iPad out of the door. Quality suffered a bit but it was quite important to be first.

I think it hurts you, if you focus on one aspect only in the long run.


NO, unless it solves a real world problem

  • Programmers usually love solving problems, sometimes to problems that don't yet exist :)
  • Programmers usually make terrible GUI's, because its a secondary thought
  • Most user problems are not the same as programmer problems.
  • Thus programmer driven product will usually be good for other programmers, but not so good for users.

Also a Note on face-book:

Face-books success has nothing to do with its technical merits, its more of a piggy back idea that just caught on really big and snowballed. Face-book et al only happen every once in a "Google Blue Moon".


  • If a programmer has a real "user" problem, one that is not a programmer problem. Then its likely that its a very good thing. If the stakeholder is also the developer that in relation to the problem is an ideal situation for a great product solution.

(Oh gosh ... where did I just read something like "I've got a great idea! All I need is a developer." It was within a week I think. Anyway ... )

Great ideas are a dime a dozen. Implementing the thing is what matters. If the developer is the one with the great idea, he can just implement it.

  • 1
    Sorry, but when you take out the platitudes and cliches, I just don't see an actual answer. Dec 15, 2010 at 2:11
  • 1
    The majority of advice I've heard on success involves "Stop talking about a good idea and start doing things to make it happen." A developer implementing his/her good idea stops talking and starts doing. So the answer to the question (in the title) is, "Yes, a developer-driven product is a good thing." If that's cliche then I'm sorry.
    – John
    Dec 15, 2010 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.