Having separate product and design teams is certainly one approach.

However, separate teams for product and design easily leads to the organisational antipattern where every feature implemented has to go through handoff between multiple teams. First product teams decide what to do, then design teams design it and hand off to UX for testing and later hand off to dev with full specification for building. When dev find that the designed/tested approach won't work due to implementation realities then it gets handed back over to the other team and so on.

Changes can take a really long time to get implemented and often no one team is fully aware of everything from the tech challenges/limitations, the cost of different approaches, the design implications, and the value of different options. Each team also has different and often conflicting motivations. Ops teams want reliability, Product want to move fast, Design want consistency. It's challenging to make good decisions on the tradeoffs in this model.

An alternative to this is vertically sliced teams where each team has all of the specialities embedded within it in order to look after a product. That means Dev, Product, Design, UX, Ops etc specialities within the team. They can then work together to add value to the product rapidly without handoffs between teams.

When cross-functional teams work well they understand both the cost and value opportunities of things they could work on, and can propose and implement features quickly and without top-down command and control.

This is classic matricial org oriented towards delivery. I've tried plenty of different orgs, and this is the most efficient structure I've been part of, or led. It's one of the leanest way of building products in discovery mode.

We're doing this at Omada Health.

It comes with its own challenges, though, as every organization:

- the leadership team needs to accept a more bottom up approach to decision making (ie LT give direction and strategy, has a power of creating teams and defining their goal, but teams decide _how_ to reach these goals)

- goals and KPIs need to be clear to everyone in the org, and in the team themselves

- you need to be clear on the values of your teams at large or individually (focus on learning/exploration? Design "quality"? Timeliness of projects?)

- you also need a certain type of teammates. Ones that sometimes can accept unclarity, ones that want to be part of whole product development lifecycle

When you have these ingredients, it's beautiful to see unfold.

You are definitely a CTO. And as one I agree completely. Without creativity in the hands of the craftsman who actually make the product there is no craft, only a tool.

As a CTO, I disagree with your disagreement :)

Engineers dont want a "script for implementation". They want to exhibit autonomy and creativity to the product as much as everyone else, especially product managers. I am not saying they should be product managers in a vacuum, but every good CTO knows the value of ownership and autonomy of a product is extremely rewarding to engineers.

I agree with both of you and tensor :)

Having dedicated people understanding what users want, what competitors are doing and what are the future directions of the market is probably necessary and worth dedicating serious time to.

It is just how people organize teams right now that seems a little broken; a Product Manager and 'their' team. This leads to the Engineers who like to innovate becoming bored and finding smart ways to get out of the 'typingpool'. This innovative talent is really necessary to scale product teams though, e.g. spotting common patterns across code bases. With that loss in innovation companies suddenly find a comparable feature that took 2 weeks taking 2 months.

Also as technology evolves new features previously impossible become possible. A Product Manager probably will not see this.

Perhaps there is a more 'ownership' heavy way of organizing Engineers. Something a bit more democratic like having a pool of ideas coming from Product Designers and Engineers. Self forming teams can come together to deliver whatever motivates them.

> With that loss in innovation companies suddenly find a comparable feature that took 2 weeks taking 2 months.

No offense to the mentioned, but the "ideas are like assholes, everyone has one" comment seems to apply extremely accurately to non-technical design and product teams who are blessed by management to throw things over to "those technical people" without any concern.

And why would a 2 week task not take 2 months under that structure? If your high-performing, creative engineers are sisyphean implementers of someone else's features without some empowerment, ownership, and accolades for the end result, good luck retaining them.

1. There's plenty of room to innovate on the implementation side. PMs don't tell you what algorithms to use or how to lay out the data in memory.

2. Not every engineer yearns to be a Product Manager. Sure, many want to make product decisions but don't want to do the other necessary work that comes with the role (like market research, metrics and analytics, managing the schedule and budget, writing PRDs, communicating with customers and partners, dealing with Legal, making sure the user manual is accurate, coordinating releases with ops and tech support, etc.) I think some techies think being a PM means merely sitting in your cube dreaming up a feature and saying "This Shall Be".

3. Good PMs most definitely need to stay on top of technology as it evolves. They need to know their platforms' capabilities and when new things become possible.

1> Yes there is plenty of room to innovate on implementation, but they still want input to the scope of what they are implementing.

2> Nobody is saying they should be product managers, I am just suggesting they want more direct input to the shape of the product itself (not suggesting ALL engineers either)

3> Agreed, and PMs should continue to be good at this, its a core part of their role, understanding the ecosystem

And indeed, that autonomy and creativity is a skill to be practiced. The best practitioners are people who lead development efforts for a company and eventually mature into their own senior technical positions (be they directors of engineering, senior engineering managers promoted from technical positions, or CTOs).

You can have all the autonomy of technical decisions you want, but you can not make business decisions and UX decisions. You can have a word about it, sure, but not authonomy about it.

making "Product" decisions is a broad topic. Who is to say a FrontEnd engineer didn't start as an amazing UX person?

I think your comment is an (IMHO incorrect) blanket statement that is impossible to apply to all engineers.

Many product designers don't understand the limits of the technology or the interface guidelines and patterns for a particular platform. It's up to the tech team to communicate any conflicts between the platform and the product decisions. Many designers try to shove an iOS ui pattern onto Android or a mobile app pattern onto mobile web, depending on where their experience and preference lies. There are also technical limitations in what can be done on UI threads or with network bandwidth or latency. These technical factors are very important to the user experience.

Having communicated these to the product and design teams, the devs must understand the tasks still get prioritized according to business needs and customer measured preference. No dev team should be implementing major UX decisions that aren't supported by data.

> You should have product and design teams that tease out user problems and come up with solutions.

If the solutions are technical, it makes no sense whatsoever not to include the tech team in the solutions.

I can't tell you how many times I've been given a "solution" that was needlessly complex at the technical level because the product team thought it was "easy" and were "helping" the tech team out. Product people often have no idea which approaches make sense technically, and worse, apparently no intuition about tech. It's amazing, really.

It definitely makes sense to have a technical person sit in on later stage product discussions to point out when minor tweaks will have significant impact on the implementation, but there are discussions that don't need technical input. IMO technical people should be brought in when making a wireframe or some other "handoff" from product/design to implementation.

The domain specialists know what their customers would like and are thus fantastic at evaluating proposals, but they don't know the range of possible solutions nearly as well as the people doing the implementation. Someone technical can propose something that the design side never considered because they didn't know it was even possible.

Having people from the technical side in there early also means helps to spread understanding of why something is designed as it is.

You beat my comment by 12 minutes. I'd add that the dev team should at least be part of the feedback loop. To bring up an example: I once worked on a project where the PMs and designers all came over from the Android project to bring up the iOS one. Many of the designs were specified to look and behave as the Android product did. A single button, if implemented according to their spec, would have meant developing a custom control + 200 lines of code-behind to mimic Android's behavior, where if we made some minor tweaks and used a native iOS-style control, it would be a one-liner (and by the way, would be more appealing users who expect iOS-like controls on their iPhones). Without this feedback, we'd probably still be building all those custom controls years later.

Oh absolutely. How to build a good product team is a challenging topic. But in my opinion a product team needs representatives from technology, design, and client facing sides. The main tasks are: collecting user problems, deciding which problems are the most important to solve and prioritize (product manager role), then design needs to come up with solutions, consulting with someone on the tech side to know what is feasible or for solution ideas.

Collaboration and communication is key, but responsibility is ultimately with each group, design with design, problem prioritization with product, and technical design with the development group.

Having been an engineer in an environment where product occasionally fails to consider all aspects of their ideas, it's critical that engineering be more than just implementation. Product needs to know what's possible in a reasonable timeframe, what looks easy but isn't, and what's possible but crosses a lot of security and privacy lines.

Engineering can and should have an advisory role in addition to an implementation role.

Removing the ability for engineers to have input on the product ultimately leads to the team feeling like a bunch of code monkeys. The good ones leave and then you just end up with the monkeys. No thanks.

Agreed, when I see an opinion like no product input from the tech team it just makes me think that the company in question would just be better off hiring contractors.

Having product and design teams be in charge of their respective areas doesn't mean that developers can't add their thoughts into the mix, they just don't get decision making power.

Why do you think a developer should have decision making power in the area of design? They are not trained in design and UX. Conversely would you be ok with designers or other non-technical people dictating technical decisions? Of course not!

As a moderately senior consultant for small to mid-sized software companies, I discuss product plans even more than I do as an in-house developer. As an in-house developer, I get salary, and that is heavily protected by law.

But as a consultant, I want to actually get paid, and paid well. If I work on ill-conceived design put together by an incompetent product team or an inexperienced founder, I'm also much more likely to have to push hard to get paid for each milestone. So I only consult when it's clear that I can add strategic value and that my client really understands their market. Once I'm sure those conditions are met, I can help them on the technology side.

When I ask my clients probing questions about their product plans, they generally seem quite happy that I care. And yes, I have advised some of them that PHP would have been a terrible choice for their technical requirements. A large part of the value a senior consultant brings is knowing how far out on the bleeding edge is wise for a given company, product and team. You want a good balance of development speed and a reasonably mature ecosystem.

The contractors mentioned are not the same as consultants. They are hired bodies, typically employed via an agency, rather than people operating a business. Whereas you're paid to think and to optimize, contractors are paid to just do without objecting.

The technology group must be in constant dialogue with the product/marketing group to create a coherent and shared vision of a profitable product. Together they form the product decision-making team.

How do you deal with the case of product coming up with a modal that needs to be scrolled even on a 1080p screen? It's certainly a UX decision and an incredibly stupid one. Should the developers implement it only to have everyone else realize how stupid it is after wasting hours or days? Or should there be someone who can stand up to product and tell them, hell no, we will not implement this stupidity? This is a real example from a real job I had. I don't need to tell you which way this originally went (we built it and of course tore it down a week later). The height or width of a modal is not a technical decision, but it's also not a product decision. You can have a dedicated UI/UX guy, but that adds a lot of cost most companies can't or won't afford. This is where the CTO, or in larger organizations, a manager under the CTO, would step up and tell product what a terrible idea their modal is and that they need to redo it before engineering considers it. If engineering can't make common sense decisions because its hands are tied and product can't make them because they're not qualified, where does that leave you with your system (the system you describe is extremely common)?

The answer is dedicated UX people. If a company decides UX isn't important to hire expertise in then I'd say it's not a company you want to work for.

Every product is designed, but if you have no UX people then the design is done either by product managers or by technical people, neither of whom are qualified to be doing that.

Ok, but what about in a startup / limited budget scenario where you can't afford dedicated UX people, something that is often the case?

Then you pick the person on the team most interested in design and get them to learn how to do design right. They become 50-75% design and the rest whatever they were doing before.

Being good at development or some other domain doesn't necessarily correlate with being good at design. Developers understand that their trade takes time and effort to learn, it amazes me that some of them can't understand that it's the same for other domains.

But we already have engineering experts in the field telling product it's not a good idea. The problem isn't the lack of expertise, it's the lack of ability to push back on a stupid task. The point is, there is no mediation here. If a UI/UX person can tell them what a bad idea is, so should an engineer be able to. Thus, engineering cannot be the slave of product in an effective organization and product that insists on its pixel perfect designs is by definition low quality (because nobody is perfect).

Different cultures. I've worked in both. Personally I prefer cultures where the engineers are making decisions. It's harder, but most developers have a knowledge gap in the domain they are working in. Having them work on someone else's interpretation of a problem often leads to suboptimal solutions. If they instead increase their understanding of the business demands they can design more elegant solutions.