How much say should technical co-founder have in deciding features/look of half-technical product?

Consider a startup that offers a specific technical solution to a generic problem in a certain creative industry. One core part of that solution is a website, and it caters to customers mostly coming from said industry.

The company's founders are two non-technical guys with MBAs and one developer, each owning the same split of equity.

None of us were part of the creative industry before, but one of the MBAs (who handles marketing and also does most of the networking) has gained a reasonable level of domain expertise.

Question:

Should decisions regarding the features and/or look & feel of the website simply be in complete control of the person that has the most domain expertise, because "all companies are business-driven" and/or "it's the job of business people to figure out what the customers want"?

However, that would leave the developer working for his own company like he would for any other in day-to-day practice (except for board meetings, of course). is this something that developers will have to accept, co-founder or not, making it a problem for way too big egos?

Or should a technical co-founder be involved in deciding "WHAT the actual product does and behaves (features, look&feel)", because it is also his product and EVERY founder should be able to identify himself with his company's products, not just with the company's general vision.

Been reading dozens of threads on this awesome site and learned a lot, yet none really address my concern.
One mostly reads about that everyone should stick with their roles and just do the job - but does this apply here?

Maybe someone even has concrete examples of where the line should be drawn between which role has what influence on what is actually needed in the product?

Thanks!

Edit To clarify a bit more...

On the marketer/MBA's side, a discussion regarding which feature will be in the product isn't wanted. The technical founder's (i.e., developer's) role should be to implement without question whatever feature marketing demands. Any disagreements from the developer's side could then be discussed at the end of the work day so as not to hinder the day's work (translation: it can be discussed after the fact).

In other words, the MBA tries to dictate the features, even the site design, instead of recommending them. Is this a normal part of fullfilling marketing duties?

The developer's ego is hurt and he wishes to be involved in deciding product features and design, despite not having studied marketing and because as a founder, he would like to identify with the product made by the company that he partly owns.

So in his mind, it should be a team effort. But rightly so?

Is the marketing guy overstepping his role? Or is the development guy overstepping his role?

Can the marketing guy more easily make his case since the company/product in not purely a technical one?

Ideally, there should be no lines. If you can't even get 3 people (the co-founders) to discuss issues and find a consensus, you are doomed from the start. Your developer should be open-minded enough to listen to the recommendations of the MBA, and the MBA should be flexible enough to understand that the developer may have legitimate issues.

Don't pull rank. Strive for a collaborative, trusting culture.

This is a great question! I'll draw on my own experience and that of fellow entrepreneurs. I see two main dynamics at work here:

1. Developing the best website possible. At this early of a stage it isn't about who is responsible for what, but it's about learning what your customers want. This will only happen if your team gets the site in front of customers and starts collecting feedback. This also requires your team to be able to make decisions quickly. Odds are that the marketer (and the developer) will be wrong about many of the assumptions regarding what should go into the website, so there's little value in internally talking about it at length. Most first-time entrepreneurs I know (including myself) make the mistake of waiting to collect customer feedback until the website is nearly complete, only to realize that it doesn't actually meet the customers' needs or fit the customers' mental model. This is wasted development time often 6 months to 1 year. Your team should think of each feature as a hypothesis and think of ways to test that hypothesis as quickly as possible. For instance, we used Balsamiq (a wireframing tool) and Powerpoint to create a mock website. And then we sat with friends and had them use the mock site (ie. usability tests - I suggest reading Don't Make Me Think, for both the marketer and the developer). At this point, the look and feel did not factor in but we were making sure the website made sense to users. We realized that many of our hypotheses were wrong based on watching 3-5 people use the site. We then took the common themes, adjusted the mock website and tried again. We iterated on the process until we built a site that made sense to our users. At which point we built out the actual site and functionality. It was much easier for us to create a mock website than a real one (but that's not always the case.)

And even after the product was built, we focused on the simplest feature set, usability tested, and then expanded. This is not to say that you should follow the same exact path, but just that the team should constantly be talking with outsiders to collect feedback to help inform the feature development.

Following this process creates buy-in from the entire team because it's no longer about 1 person's opinion but it's actually about the customers. A good exercise it to list out all the hypotheses on a whiteboard and figure out how to test them with outsiders/customers.

2. What if the marketer doesn't believe in this process? This is certainly a very real challenge. At this point the developer should go out and do his own usability tests with customers. Screencast them if possible along with audio. Or pay for a service like Usertesting.com. The developer can then take these usability tests back to the marketer and show him what the "customers" are saying. Remember, that it's not about who is right or wrong but it's about finding the best solution. So the developer should also highlight instances where he had a hypothesis that was wrong to put the marketer at ease. It'll be hard for the marketer to argue with customer feedback.

At this early of a stage, everyone should be learning about the customer as it will make each of you better at your respective jobs.

Is the marketing guy overstepping his role? Yes, and no. Mostly no. Here's why. I've seen both business types and devs make academic arguments from non-data as to why a certain product should be X, Y or Z, but ultimately the MBA types are looking at the same issue as the devs with more of a bird's eye view. I would even go so far as to say that it's a conflict of interest for developers to be to involved in the marketing of their own work. They're simply too close to it.

Or is the development guy overstepping his role? Yes and no but mostly yes. The MBA types interface more often with the types who land big accounts and give the company momentum and critical, high-level feedback. This is an opportunity for the developer to practice letting go, something I've watched very successful founders do throughout a company's growth. Not always pleasant but a side effect of growth.

Can the marketing guy more easily make his case since the company/product in not purely a technical one? Based on my experience, I would say that in this instance, the considerations of the individual in the marketing role trump those of the dev's.

Everyone on a team has to have a stake, a personal sense of ownership of their domain, otherwise morale plummets and they start watching the clock.

The dev already owns the technology side, the "how." They interface with the engineers and the systems.

The marketing/business types interface with the customer base and the accounts themselves, they have their finger on a different pulse but it's one that directly affects the bottom line. It's a bigger picture view.

Another note - push-back from one party on features, design etc. is OK as long as it isn't interminable. Ultimately someone needs to concede, and someone needs to lead.

Someone should have the last word on these decisions, and in the absence of pragmatism or some compromise, it's up to a third party to step in and set the course. In my opinion, it is that wherewithal for "dirty work" that separates executives from everyone else. They should see the big picture, resolve these things decisively, and everyone else should follow the leader.