I like the separation of The Company, but highly disagree with keeping The Customer separated from The Product.
I would like to see more of what can be done as we focus more on combining these, not segregating them.
As a developer the very rare chances I have had to go on a sales visit were eye opening in an astounding way. Sure, maybe don't have developers cold calling, but making product developers a part of the sales process can only help with the feedback loop.
Some segregation is inevitable. It's a result of complexity. At a certain point, the company becomes too big and complex for everyone to be doing everything, and you need to specialize, not just distribute the work.
The Product/Customer divide makes sense to me, because what you do about them is different. Sure, customer steers product and vice versa, but the "Customer" machine is about sales funnels, marketing language, customer service, etc. The "Product" machine is about specs, coding, release schedules, etc. Implementing a new feature and selling a new feature are different tasks, requiring different skillsets.
The branches should never be separate, in the end every branch cares about final product, that it sells.
What is missing in the model is strategy - there should be people responsible for an overall strategy. That part requires communication with all branches while having a general vision. In a small company, that function always belongs to CEO.
Next, someone who cares about internal company health. In some companies, this would be called "operations". Those people would handle adherence to rules, mood and day to day infrastructure. (maybe part of hiring process)
Think of them as legal branch of a government.
This makes it four.
Tossing these two as one (company machine) is problematic. Strategy needs to "be plugged into" all of the processes quite directly, as well as being aware of external conditions.
I think your hangup may be more about the words Brad used to describe the 3 machines than their actual functions (which I totally understand. I had the same initial reaction to Brad's post. Across the board, every part of the org should be customer-focused.)
Another way of naming these 3 distinct operating groups:
Build | Acquire | Operate
Or in our company's case,
GTM - Go To Market | EPD - Engineering, Product & Design | G&A - General & Administrative
I don't think Brad meant to imply that only one branch was focused on customers. I think it was just a simplification to make the names more accountability-focused & less function-focused, as Brad worked through it.
(
NOTE: I'm an employee of the company that sparked this post.)
How is this deep or smart? It reads like the common armchair "this is how to run a company" without so much as an anecdote. In fact, the foundation is his unnerving preoccupation with the number 3, not with any eye for business.
> there’s a lot of sloppy thinking on my part so far
That's from the blog post. Mistaking amateur ramblings for analysis is bit worse than seeing someone's mediocrity as genious. What are the standards for analysis now, 2 beers and a couple paragraphs about how the world should be?
Brad Feld is a very successful VC. Those aren't amateur ramblings, those are professional ramblings!
More to the point, he's a longstanding and well-respected business advisor, and has an excellent track record. I may or may not agree with him on any given subject, but I'll sure as heck stop and listen, because he knows more about this stuff than I do, by far.
I like the idea a lot, like the author wrote, he acknowledges there is still a lot of thinking to do but I like the consolidation of Executive positions into three buckets.
I think an executive mastering the customer machine, another the company machine and another the product machine, will allow each of these critical areas to sing. There will be conflicts and fight for resources sometimes but understanding you are all three silos that also come together to work for a greater good is a powerful motivator and I think can allow the company to see its mission more clearly. The idea needs to be fleshed out more but I applaud the direction
Advocating a ternary structure isn't particularly insightful, and ternary trees aren't particularly efficient as data structures (they're to rebalance, etc).
As I'm making my first hires this month, I've been thinking very heavily about future org structure - and oddly enough I've called it the "machine" too.
My machine has custom components that perform different functions but connect together (which parallels your machines pretty well). Each of those machines can be subdivided to an extent.
I think it's an interesting approach in that I could practically design draw a schematic to describe how it all comes together. Every company would probably need a custom-built machine - there's no general one-size-fits-all approach in this way of thinking about it.
Early-stage business advice is cheap and sometime barely worth the bytes it's stored in, but...
Speaking as someone who has done a few startups. Until you get to 50+ employees you probably don't want to spend a lot of time thinking about the org structure. Keep it relatively flat (CXOs -> VPs -> Everyone Else)
It is less cognitive load on you and empowers individuals to help form the company culture and workflow.
Edit: I don't really agree with the premise of this article. I think it is critically important at early stages that everyone (engineering, marketing, sales, customer service, etc) are exposed to every part of the business. If a customer sends customer service a great review, engineering should see it. If a customer has an issue, engineering should be involved in making the customer happy. And the other way around, customer service should have a say in how the product is built... heck, the administrative assistant that answers the phone should even have an avenue for their feedback to be heard. Of course someone needs to ultimately make the decision but everyone should have a voice and feel vested in the company success.
> If a customer sends customer service a great review, engineering should see it. If a customer has an issue, engineering should be involved in making the customer happy. And the other way around...
100% agree with this sentiment. I have tended to work at small (<30 headcount) companies and the better ones fully adopted this mindset. The less good ones tried to insist on closed doors and "you only need to know X" - which ultimately led to complete apathy to other departments problems or successes.
I kinda like the idea of separating the "Company Machine" from "Customer Machine" and "Product Machine", but Customer and Product are deeply intertwined.
Another reason I don't like the customer/product split is because it pits the Customer team against the Product team. Who is the most valuable? Gee, clearly the Customer people because they bring in the money... Product is then treated as a cost center
Yes, I think Company machine ~ HR; it is often separate from other two in the real world. And IMO the risks of putting management walls between Product and Customer, even in a small company (7 people example) are high. If product is not tightly plugged into customers one risks making something fun to build and useless / unsellable.
I like this clarity. But I think to make it work you need the best people at the boundaries of the divisions. Between customer support and product development must sit someone, or a team, with experience of both. Between the internal company function and the engineers must be a former engineer who is now a manager or at least a person who both understands the business and also understands that programmers need quiet offices and decent equipment.
As the founder of an early stage startup, everything that is not related to product development seems that I am not actually working. I know that I should devote myself to hone my Customer and Company machines, but I hate the feeling of wasting time.
I am trying to transform Customer and Company as products, so I trick my mind to evolve them appropriately.
Very true. The hard part seems to be finding the hierarchy. Can the head of Sales ever not be the head of Customer? (Can the head of customer success have the VP of Sales report to them?) Having product management subservient to engineering or vice versa seems tricky too.
So if you're working on technology that enables the company to build products better/faster, is that part of the product machine or the company machine? At what point do those technology projects become internal enough to be considered Company instead of Product?
If I am understanding his point, the Company machine is basically finance/accounting, legal, HR, and office management. It is a common pattern at mid-stage startups to have some or all of these people report to a CFO. If your product is to make software to build products, the product development is still under the Product Machine, even if the company itself is using the product.
Readit News
I would like to see more of what can be done as we focus more on combining these, not segregating them.
As a developer the very rare chances I have had to go on a sales visit were eye opening in an astounding way. Sure, maybe don't have developers cold calling, but making product developers a part of the sales process can only help with the feedback loop.
The Product/Customer divide makes sense to me, because what you do about them is different. Sure, customer steers product and vice versa, but the "Customer" machine is about sales funnels, marketing language, customer service, etc. The "Product" machine is about specs, coding, release schedules, etc. Implementing a new feature and selling a new feature are different tasks, requiring different skillsets.
What is missing in the model is strategy - there should be people responsible for an overall strategy. That part requires communication with all branches while having a general vision. In a small company, that function always belongs to CEO.
Next, someone who cares about internal company health. In some companies, this would be called "operations". Those people would handle adherence to rules, mood and day to day infrastructure. (maybe part of hiring process) Think of them as legal branch of a government.
This makes it four.
Tossing these two as one (company machine) is problematic. Strategy needs to "be plugged into" all of the processes quite directly, as well as being aware of external conditions.
Another way of naming these 3 distinct operating groups:
Build | Acquire | Operate
Or in our company's case,
GTM - Go To Market | EPD - Engineering, Product & Design | G&A - General & Administrative
I don't think Brad meant to imply that only one branch was focused on customers. I think it was just a simplification to make the names more accountability-focused & less function-focused, as Brad worked through it.
(
NOTE: I'm an employee of the company that sparked this post.)One could do worse than to consider those three areas in any decision.
> there’s a lot of sloppy thinking on my part so far
That's from the blog post. Mistaking amateur ramblings for analysis is bit worse than seeing someone's mediocrity as genious. What are the standards for analysis now, 2 beers and a couple paragraphs about how the world should be?
More to the point, he's a longstanding and well-respected business advisor, and has an excellent track record. I may or may not agree with him on any given subject, but I'll sure as heck stop and listen, because he knows more about this stuff than I do, by far.
I think an executive mastering the customer machine, another the company machine and another the product machine, will allow each of these critical areas to sing. There will be conflicts and fight for resources sometimes but understanding you are all three silos that also come together to work for a greater good is a powerful motivator and I think can allow the company to see its mission more clearly. The idea needs to be fleshed out more but I applaud the direction
My machine has custom components that perform different functions but connect together (which parallels your machines pretty well). Each of those machines can be subdivided to an extent.
I think it's an interesting approach in that I could practically design draw a schematic to describe how it all comes together. Every company would probably need a custom-built machine - there's no general one-size-fits-all approach in this way of thinking about it.
We'll see how it goes
Early-stage business advice is cheap and sometime barely worth the bytes it's stored in, but...
Speaking as someone who has done a few startups. Until you get to 50+ employees you probably don't want to spend a lot of time thinking about the org structure. Keep it relatively flat (CXOs -> VPs -> Everyone Else)
It is less cognitive load on you and empowers individuals to help form the company culture and workflow.
Edit: I don't really agree with the premise of this article. I think it is critically important at early stages that everyone (engineering, marketing, sales, customer service, etc) are exposed to every part of the business. If a customer sends customer service a great review, engineering should see it. If a customer has an issue, engineering should be involved in making the customer happy. And the other way around, customer service should have a say in how the product is built... heck, the administrative assistant that answers the phone should even have an avenue for their feedback to be heard. Of course someone needs to ultimately make the decision but everyone should have a voice and feel vested in the company success.
100% agree with this sentiment. I have tended to work at small (<30 headcount) companies and the better ones fully adopted this mindset. The less good ones tried to insist on closed doors and "you only need to know X" - which ultimately led to complete apathy to other departments problems or successes.
Either that or it's late and I'm getting philosophical.
I am trying to transform Customer and Company as products, so I trick my mind to evolve them appropriately.
Deleted Comment