The Yin and Yang of Product and Engineering
For a tech company, product and engineering are the heart and soul of the business. When I do a quick mental query of headcount across our entire portfolio of ~30 companies, I think at least 50% and maybe as much as 60% of the entire headcount of our portfolio is in either product or engineering.
Many of the founding teams we back include a strong coder and a strong product person. A typical configuration is the founding CEO is also the "VP Product" at the start. This is a great configuration for a starting team. The two individuals can and should build a tight knit relationship with each focusing on their particular roles in getting the product built. The product person sets the overall requirements, specs them, focuses on the UI and UX and manages the process. The engineering person builds the product or manages the team that builds the product, or both. The yin and yang of product and engineering are represented in these two founders and their relationship and combined effort is what gets the product out the door.
As the company scales the yin and yang of product and engineering often gets out of whack. What typically happens is that the engineering team scales and the engineering leader either scales with the team or hands over the job of managing engineering to a seasoned executive. But the product side often does not scale in the same way. Many founding CEOs who are also acting in the VP Product role attempt to do that job for too long. Or they bring in product managers but don't build a highly functioning product organization. And hiring a really strong VP Product is often an afterthought.
I have seen many companies go through this phase. What happens is the company starts having trouble getting product out the door as rapidly as it had in its early days. Other issues start cropping up and the engineering team has to focus on them. A typical one is technical scaling issues. If the service is popular, the entire engineering team can get pulled into firefights related to scaling issues. And I have often seen companies spend a year or more rebuilding the guts of their product to make it scale better. During this time, product related efforts can languish and feature development takes a back seat. This period in a company's development is brutal on the product team who gets frustrated with their inability to move the ball forward.
The prescription for these problems is two fold. First, the company needs a strong executive in both product and engineering. I say executive because the key skill set is the ability to manage people and create organization structures that are highly functional. The VP Engineering and the VP Product need to have a history of being highly skilled engineers or product managers, but in the role of leading these organizations, those skills will not be the ones they use. They will hire, fire, organize, manage, resolve lingering issues, and make tough decisions. They will be managers. And these two individuals need to pair up in the same way that the founding team did. They need to be partners with each other and reinforce each other. The ability of the VP Engineering and VP Product to work well together is so key to building a great tech company.
The second thing that has to happen is that product and engineering resources need to be divided up into small teams that actually build stuff. Teams should be between three and seven people. Anything more than that
should be broken up into two teams. Each team needs to have a product lead and a tech lead. And just like the two founders and the two VPs, the two team leads need to partner up and work well together.
So hopefully you see that this yin and yang of product and engineering must always be at the center of the company and they need to be in balance. If you have a super strong engineering team but a weak or understaffed product team, you will struggle. If you have built a functioning organization in engineering but not in product, you will struggle. If you have a team where one of your two team leads is weak, it will struggle.
If you are stuck between being the scrappy startup you used to be and the highly functioning big company you want to be, look at your product and engineering organizations and make sure they are well balanced and that you have strong leaders in both who work well together. If you don't see all of those things, think about making some changes to get there.
Great post.You just neatly summed up why I chose the co-founder I have. And maybe we should think about looking for a great VP Product earlier than I thought… a role that’s incredibly difficult to fill in Europe. We don’t have that many consumer-facing web businesses that have trained people well.
one of silicon valley’s greatest strengths over the rest of world is the quality and quantity of great VP Products. NYC suffers from a lack of them too Max
The timing of this is funny as I just complained to a fellow startup friend in NYC that I never saw any job postings for ‘VP Product’ or ‘Product Manager’ in the area when I was looking for work. People seemed to want an ‘engineer who knew a bit about product’ or a ‘lead designer who built products.’My ‘I’m great with wireframes, mockups, and concepts!’ resume flopped.
Willing to move to Europe? Link your profile! 🙂
Thanks for the interest Max 🙂 I actually gave up my search a month or so ago and took it as a sign that I should pursue the startup that my Fiance and I have been dreaming up for the past year. Put together a small team and we’re working on it at night when we get home from our day jobs.Here’s my profile in case you want to connect 🙂 http://www.linkedin.com/in/…
Awesome, good luck!
A boilermaker. Do you have a link to your start-up’s site to share, or not yet?
Not yet, Dave. We’ve just pushed our first prototype this morning and are currently playing with it :)It dawned on me this morning that each comment I post without attaching a link to even a splash landing page is a waste of an opportunity :(So! I just spent a few minutes putting together the most simple site possible.http://getmochi.com/
I like your logo, of the anthropomorphic mochi. Also, this blog post of yours was interesting, where you talked about the ROI you got from different approaches to marketing your fiancee’s salon, including Yelp, Twitter, etc.Good luck with this.
Thanks for taking the time to read it 🙂 Do you mind if I ping you when we have something to show? Would love a follow-up opinion when the time comes!
Sure, please do.
I am in Europe already (Kiev) and I am the product guy 😉
As I was reading this post I couldn’t help but think about Google. Its TV product this week is just one example, but also others before would lead one to believe that the VP Tech has much more influence there than the VP Product. (Figuratively speaking.) Its adversary, on the other hand, seems to be much more balanced, and maybe this is because Jobs knows both parts of the business well. So, moral of the story… I wonder if the yin and yang are a function of balanced CEO.
“I wonder if the yin and yang are a function of balanced CEO.”Totally.
As I said in my posterous reblog of this piece: “What would I do without Fred Wilson’s wisdom? The guy validates and cleanly articulates 1 out of every 2 lessons I learn the hard way, and foggily perceive.”This is probably, for me, the most timely and relevant of many posts by you that I have found to be immediately useful in my decision-making. Though the team I lead (for trailmeme) is an intrapreneurial team at the Xerox Innovation Group rather than an independent startup, I’ve found that most things you say port directly, with no hacking required. As the internal ‘founder’ I was playing exactly the combo ‘CEO+VP product’ equivalent role you mention, and am just attempting a separation, for exactly the reason you suggest. Fortunately, I have a very strong pair of people to lead engineering and product, and I have high hopes for a successful transition. Your other predictions (scaling issues etc., distracting from product…) are also starting to play out on schedule.I don’t know whether you forgot to mention it, or whether it is just not as common a pattern, but the reason I am trying to separate the general ‘CEO equivalent’ role from “VP product” role is that I need to really have marketing and strategy front-and-center for myself as the priority. It seems to me that the yin-yang issue also has a (pardon me) third ‘yong’ component driving the equation: the growing priority of marketing/”customer development” as the product and engineering become increasingly capable of sustaining it. This role, I find, is the hardest to fill later in the game, if you don’t have a marketing-type lead in the founding team, who has grown with the product. I am refactoring roles and responsibilities to take the lead on this front myself primarily because I can find almost no good candidates for this role. I make no apologies for the non-ideal starting composition of our team, since I imagine lots of startups begin with purely tech startup teams (as ours did), and have to solve the marketing problem a little later in the game (this is especially an issue for intrapreneurial projects that start within industrial R&D labs like ours… there is very little history or tradition of having a strong biz-dev/marketing function to draw talent from, though this is starting to change).Thoughts on this question? I hate to complicate your nice yin-yang dichotomy into a messier yin-yang-yong trichotomy (product/engineering/marketing), but I see no way to throw out the last variable without fatally oversimplifying the situation.Venkat
yes, you are right. as the product turns into a business, the CEO must turn his or her attention to the business and away from product and that is a big part of it. interesting that Reece also mentioned the customer facing part of the business in the comment above
So perhaps a future post on this stuff.? I haven’t seen much from you on the lean startup/customer development ideas doing the rounds (unless I missed some posts).
Venkat – if you define marketing as outbound communication about the product, I think that is a 3rd role. You also mention “customer development” – responsibility for this surely has to broadly fall under the remit of the product manager given the intent of that activity is to validate / refine the product vision.PS If you enjoyed this post I also recommend Marty Cagan’s product management blog, it’s a fantastic resource – his thoughts on division of product management vs marketing are here – http://www.svpg.com/product…
Niall: The link is interesting. You are right, ‘outbound’ is a 3rd role (and easy enough to carve out, since it is well-defined and bounded). It is the rest of marketing (inbound, positioning, segmentation, customer dev) that is hard to carve out. I don’t believe you can find somebody capable of all that AND capable of the UX-level attention to the product very easily. So no, I don’t think this falls ‘broadly under the remit of product manager.’ Attention to product and attention to market are a zero-sum pair IMO, and as the very title indicates, “product” managers must primarily focus on the product/UX and abstract user personas, not on direct customer/market work.But this is a very tough and ambiguous talent management problem. I doubt there are many general lessons. The personalities of the actual team members and constraints of who you are able to find etc. ultimately drive 80% of the dynamics.
Venkat – I have to disagree on the “zero-sum pair” argument – I think the best product managers are capable of effective competitive positioning, customer dev and UX design – all are “product” activities. Without input from that work it’s just a product designer role operating in a vacuum or via some tired MRD. I think the most successful founding teams manage to nail both dimensions.
“I hate to complicate your nice yin-yang dichotomy into a messier yin-yang-yong trichotomy (product/engineering/marketing)”You make an important point, but I don’t see how that contradicts with what Fred says. It adds to it. And there is more than one organizational frame that can work.
Of course. Complication and contradiction are not the same thing.
There was a number of discussions about this at Next NY Product Manager school- one of the ideas that came out of it, the product manager at an early stage startup often is marketing too, since you crash and burn or fly high on your product when you are a small company. (It needs to at some point, sell itself.)
Well said. There comes a point in the maturity of the product where its needs real “product management” which a strong VP, Product can provide vs. the visionary style of product management that a founding CEO may have provided at the beginning. But you don’t want to bring too much structure and process too soon, as that puts innovation in the backseat.I’m not sure that the issue of scalability is totally related to the ying and yang relationships. Architecture & scalability is something a strong CTO should be able to plan for, early on.
Awesome knowledge here, Fred.Curious though, where in your experience does customer support/sales staff come into play?As a small team, we interact directly with our customers often, which helps us develop the product and relay that to our engineer. How does this typically play out with scale?
i think it is a good idea to get a customer facing person (sales or customer support) on every product team. having that input can really make the difference
Absolutely key to be customer focused. The founder/CEO of a startup I follow has every customer support email forwarded to the entire company. Her people sometimes grumble about it but she insists on doing it and will keep doing it until it can’t possibly scale. She reads every single customer support email even if she doesn’t respond to them all. The technique aside, it shows the kind of customer focus that I think absolutely key.
Completely agree. I always tend to neglect this step and it is eyeopening how a small project can flounder when the customer service component isn’t there. I understand the 37signals “everyone is a CSR” idea, but when you have one person who lives and dies by your community’s happiness, your product person’s life is SO much easier.
I would go one step further – you talk about the executive leadership of the VP Product/Engineering, you also need VP Sales/Support right in the trenches as well – product decisions need to be made quickly and with as much customer input as possible – who better to take responsibility for that than the people who are in front of the customer every day? Even if the VP Product and Engineering are doing everything right, without the constant customer feedback, it’s less likely to succeed than a poorly functioning Product/Engineering team but with great customer feedback.
Totally. The customer advocate hears about the customer’s pain first, knows which topics bubble up and this helps prioritizing.We call our product team The Product Council – sounds like a band name too.
IMHO, in the new world order of open source production communities and federated networks, the concept of “product” changes from software to community/culture/brand. that’s where i think the anthropologist you guys want to hire comes in. software gets pushed out of the firm (i.e. to the edge) where it is created by open source production communities. a federated network of such companies will work to govern the open source production communities for the software they use, but each company’s focus will be not on software creation but on community creation.
While I agree that community creation is becoming more and more essential, it’s very difficult to derive your product vision from an outsourced production community. If you’re implying that the product manager’s role becomes nurturing that open source community, I could see that, but if it’s building a community around the product itself, that’s a long shot. Good product people are not necessarily good community builders and vice versa.
yes, i think it involves the product manager basically managing an opensource community. but as there will be multiple firms that work together tocreate a federated network (i.e. they agree to adhere to the same technicalstandards) each firm may not even need a product manager; there only needsto be one or several product managers that manages open source softwareproduction communities for the entire network that has agreed to the sametechnical standards IMHO.
This is kinda interesting. Do you follow game development at all? There’s a similar belief there that the game ‘designer’ (like a product person) is the one leading a number of outsourced teams. Granted, they aren’t open sourced (which imo is a bit utopian in this day and age), but they do work for small change and the product person weaves their output together to create his/her masterpiece.
yea — and community (like language) is a technology… but one that seems to be anathema to US ideals(?)
Fred, I’ve seen this happen in mid-sized organizations – especially the ‘product stalling’ you describe.What has your experience shown for the separation of product vs. engineering in a fledgling startup?We are 4 people (2 designers, 1 product, 1 developer) who came together via friendship and started building something. As the product person, I began to become frustrated with the speed of our development (designers significantly outpacing dev) and started to bridge the gap by coding in my spare time.I’m not a great coder.Have you seen a group like this (specifically the product guy wearing an engineering hat) succeed?Our thought at the moment is ‘do whatever it takes to get the damn thing out the door ASAP.’
in a team as small as yours, get the damn thing out the door is a greatmantra
“2 designers, 1 product, 1 developer”That explains the slow pace. Three people breathing down one neck.
Completely agree. I’ve jumped onto the coding side (limping is a better way to describe it) to try to combat this. At the moment I’m slowing our coder down a bit but my hope is that in a few months I’ll be sprinting alongside him. We’re also considering bringing in an outside coder that we know fairly well but are worried about the whole ‘paying him’ thing as we are all working for free via ‘potential equity.’
Absolutely excellent and true.I would add a caveat that sometimes you don’t need to hire a VP Product because the CEO is a genuine product visionary and having an “experienced” VP Product could kneecap him. Apple is the obvious example, but so is Facebook, and Twitter’s early days as well.
But Apple does have a pretty extensive and structured product group, and I think that’s part of Fred’s point: Jobs (or “the CEO” in the abstract) may well remain the visionary for the product(s), but as the organization grows it’s less and less realistic for that person to be involved in every decision.The VP Product and the process/structure that they create are what make it possible for the CEO to define a product vision even when they can no longer spend every waking hour deep in the product.
Right, obviously there are product teams, but there is no “VP Product”;there are product groups and VPs software eng, hardware eng, design, etc.The CEO *is* the VP Product. With the right CEO, it’s the best setup. (Ofcourse, with the wrong CEO, it can be the worst.)
As the organization grows, it does make sense to end with “a pretty extensive and structured product group,” but even then the top person can get deep in product development. Often that is a good thing. Larry Ellison does a lot of that.
But my point is that even if the ceo is an amazing product person, you still need an executive managing the product team
Apple is a great example. At Facebook though, Zuck is also a great engineer himself, although I doubt he codes anymore.
“The second thing that has to happen is that product and engineering resources need to be divided up into small teams that actually build stuff. Teams should be between three and seven people.”Hear. Hear. Even three scares me. The more you can break the thing into pieces owned by even one engineer, the better the chance you have of meeting dev schedules.I find there are always really strong coders who are blindingly fast, and when it becomes a multi-man job I get a sinking feeling.Also if you haven’t seen it, check out Balsamiq. It makes life so much easier.
Fred, I’m not convinced VP Product and Engineering roles have to be separate in small team environments. There are people out there who have strong engineering backgrounds and also understand the product development process. Those folks can fill both roles in my opinion.
I think once the company gets above fity or so, it becomes critical
The problem with having a separate VP of product role is that in a star-up, there are usually very few product managers. The # of engineers are going to outnumber the number of PMs. And it’s likely that the engineering VP has a lot more power than the VP of product. This happens a lot in start-up unless the CEO really understand the role of product management, and stand fully behind the VP of product. Otherwise, I’d prefer to have a strong VP of engineering with good business background, and having a Director of Product reports to the VP of engineering.
Fred,How important do you think engineering background is for product leads? I see this requirement a lot, especially for West Coast startups.Clearly you want someone who isn’t going to ask for things that are technically impossible. My take is that I’d rather have someone in the product role who is UX/partner/market focused.
Speaking from personal experience, I’ve worked with product people who don’t have an engineering background, and they generally can’t talk to developers. It’s great to be able to talk to designers, understand UX, etc… but if you can’t talk to your devs, you always rely on your lead developer to strategize all engineering decisions.
I think the desire of West Coast startups is a mistake. When a product manager asks for the technically impossible, the ensuing discussion/solution might be revolutionary.On the other side, when the former coder waters down his/her requirements to make it technically feasible, the product manager can easily slide into the role of project manager.I agree that being user focused is key.I have heard comments like bdickason’s many times. While I agree, I have also found numerous developers who can’t talk to product.
Good point. Being too aware of the current constraints sometimes limits creativity. On one project I worked on, the first reaction was “the index isn’t set up to do that.” Sure, but if the idea is big enough, maybe it makes sense to modify the way the data is indexed.Start with what you want to accomplish for the user, figure out if it’s worth doing and then work closely to figure out how to make it happen.
“When a product manager asks for the technically impossible, the ensuing discussion/solution might be revolutionary.”A great product person may or may not be an engineer. Not to say not being an engineer is what makes a great product person just like having the engineering chops does not automatically make you a great product person, or a product person at all.
A product manager who can’t code at all is like an author who needs to dictate their books to a stenographer. It can be done but it’s a huge disadvantage.The power of being able to hand engineering a functional prototype is HUGE. It can be a hack. It can be spagetti code. You can “Wizard of Oz” the back end. It does not need to be on the same framework as the product will be built on. It doesn’t need art. But being able to say “this is what using the product is like” is incredibly powerful.
“A product manager who can’t code at all is like an author who needs to dictate their books to a stenographer.”Bad metaphor. Cry me a Mississippi. (sp?)
Perhaps if you expanded your flippant reply it might make more sense. I have no idea what you mean by “Cry me a Mississippi.”I’ve been doing product management for 22 years; long before there was an internet. I’ve run big product groups, and small, in start ups and in S&P500 companies (and going from a start up to an S&P company). I’ve done it for hardware, SW, online and hybrid products. I’ve hired and fired dozens of PMs. Before I was a PM I was briefly a SW engineer mostly working on UI.You don’t need to be a GOOD programmer to be a SW PM, but you need to be fluent with SOME toolkit that allows you to express interactive ideas on screen. A PM who can’t do this slows things down and in many cases you’re better off without. The problem with a PM who is not conversant in SW vernacular (not just buzz words) varies by the scale of the company.In an early stage (pre-product/market fit) the iteration cycle is too fast. A dozen ideas get tossed out in a week, rapid prototypes are a good way to separate wheat from chaff. A rapid prototype wil expose problems in seconds that all the paper mockups in the world won’t expose in a month. If you can’t prototype these yourself (in particular YOUR ideas that YOU are advocating to the rest of the team) then you are dependent on someone else to express your creative vision. This makes you ineffective.In the growth stage the issues are different. You need more of an engineering background. The devil is in the details. It’s about understanding edge cases. It’s about understanding trade offs with legacy systems. You’re asking an enormous amount of engineering, if you don’t understand what you’re asking for you can’t know winning this particular battle is worth the cost.In a big company where some politics has set in the dynamic is different. You need to know when someone is blowing smoke up your ass.Here’s the last thing. It’s not that hard. I can’t stand hand waving, high concept, BS spewing PM’s. Go get a job in marketing, not product management. If you’re not working hard enough at being a PM, if you don’t find being crippled by your lack of conversational SW tools, if you don’t find that it is unacceptable that you aren’t fluent in SOME tool– IMHO you’re lazy and you don’t care that much about your craft.Sorry about the rant. But this is something I care about and have seen done poorly a lot over the years.
The stenographer is just putting down the words. But that is not what an engineer does.
If the product manager has no skills with a prototyping tools that’s exactly what you’re asking the engineer to do and it’s a HUGE waste of his/her time. Why waste engineering resources finding fatal problems that a PM who can prototype would find on their own?
You have a strong bias for product people who are also themselves engineers. I don’t think that is bad. But I mean to suggest there is also an alternate school of thought. How much coding Steve Jobs ever do or has ever done?
He’s pretty good from a technical standpoint actually… In the early days he laid down transistors for Atari. Wozniak did most of the technical side because Wozniak was a genius when it came to that stuff, but Jobs himself was still pretty decent, which possibly is what allowed them to communicate well.(My source for that is an interview from Wozniak in Founders at Work)
Good to know.
You are vastly underestimating Steve Jobs.You didn’t work in the valley in the 1970s without real geek skills. He’s written plenty of code (much of it in assembly).The Valley was a different place back then. Plain and simple you could not even operate a computer of that era without being technically pretty adept.
I remember Steve Jobs saying somewhere that he teamed up with Woz because “I wanted someone who knew as much about electronics as I did.” Larry Ellison once said that he was a “really good programmer.”
I’ve seen many different backgrounds work. But having a background as a coder sure helps the communication
True … but that seems to put the onus on the product manager to translate his/her ideas to be able to be understood. If we are talking about a true partnership (and we are, and we should be) then we need to reframe the dynamic so that both sides meet in the middle.As an atypical product manager (I was a strategy consultant), I find that many of the product managers I meet come from the technical background you are describing. To me (and I am generalizing here) they tend to be lacking something. The external, customer-facing, end user, marketing roll out, perspective. What is the marketplace for my product? How do I make people try my product? Would they pay enough to make it worthwhile? Would they pay enough to justify a sales force? And many other business/strategy/opportunity/marketing questions. That said, these should not dominate the product build out either – but a true, creative, dynamic partnership should not be two people with similar backgrounds (just that one is so much more technical than the other).I guess I am saying that if you frame “communication” as “translation” then an ex-coder would be a valuable background. I just believe a creative dynamic comes from a “communication” that is based on expanding the scope of the discussion, bringing alternative perspectives into play, Otherwise, a lot gets lost in translation.
I totally agree with where you are going here. Communication is the key.Among these comments, many people here have touched on the three building blocks for effective communication – speaking in one language, everyone sees how they fit together, and the process or stages of communication are progressive.In my opinion, communication is not smooth between product managers and engineers because each is focused on inherently conflicting objectives rather than complementary objectives. The product designer is focused on benefits to the user and the technology developer is focused on the most efficient way to gather user information to generate ad revenue.So I think success starts with recognizing that Yin and Yang is not about conflicting opposites. “Yin yang are complementary opposites within a greater whole.” (source:Wikipedia)Complementary does not mean everyone has to be all warm and fuzzy. (Friction is good for innovation – I like the metaphor of a match needing friction to light it. But when there’s a stand-off you’ll never catch fire). To come together, opposites recognize a mutual benefit in being a part of the “same greater whole”.When you start there, all sides are speaking in a common language and everyone sees how they fit together. Instead of arguing about who has to translate for whom, or where one’s role ends and the other begins, you can focus on planning the progressive stages of communication.If all that sounds obscure and esoteric (I have a cold my brain feels like mush today) I’m trying to say – it is incumbent on all parties to speak a language everyone understands, including the person who is validating the value of what you are doing with their hard earned money. If that’s not the “greater whole” you are a part of, then you are destined to an eternal circle jerk.Katherine Warman [email protected]
Great post, this area and issue is the key to almost everything in the early days.
I see the importance on a theoretical level, particularly regarding organizational framework. But I’m having trouble envisioning the execution part of the equation. When hiring a VP Product in a software company, how do I create the bright-line distinctions between Product and Engineering? Or should the line be intentionally blurred in order to (eventually) get the most from both teams?
The two execs need to define that line and enforce it
I’d be worried about not always having an overview of product development if I fully passed that on to someone else. My experience has given me a pretty solid understanding of factors that need to be included, or the disadvantages there are to certain elements for UI and UX.”This period in a company’s development is brutal on the product team who gets frustrated with their inability to move the ball forward.”My own personal recurring frustration with not being able to move the ball forward as quickly as I’d like is when I decided I needed to focus on learning how to get VC. I’m almost there, I just don’t have a formal presentation yet.Soon I’ll be ready to take it from Qcards pinned to my corkboard to digital form.P.S. I’ll be in NYC either June 6th (or 7th) and at least until the 9th if anyone wants to meet up to chat! A few people in here I’d love to meet. Can always @mattamyers me too. 🙂
During the scaling stage I’ve seen engineering become 80+% of headcount. Often the CEO gets swamped with Engineering stuff so has a hard time focusing on building the Product org. How often is a CEO change made about this time so as to re-balance product and engineering? Or can the re-balance be done by the existing founding CEO?
I think the reason for that unhealthy imbalance of too many engineers and not enough product people comes from the attitude where people basically look down upon product people, and being a product person is not considered a skill set. Engineering is a skill, but product development is just common sense, anyone can do it on the fly: that seems to be the attitude, also reflected in many comments here. That is unhealthy.
if product was the magic dust of common sense and design, there would be no innovation to it.Product is supposed to be the answer to huge questions, and enigneering is the how to do it.
Communication between product and engineering is key. In the beginning the founders are in direct contact with users/customers much of the time. As the business scales it sounds like the focus moves to include spending time working on the business infrastructure, and internal organization.While product and engineering leads work in harmony, the startup team must balance external and internal growth. If one outpaces the other I can imagine things going out of whack rapidly.
I have taken to not commenting on every AVC blog post, I have taken to not reading all the comments, but this blog post is one that asks for an elaborate comment, and an immersion in the discussion/disqussion. I guess a Saturday puts more time on your hands.You can be a great product person without being a techie. But you do have to have the vision, and you do have to follow the tech nuances. Steve Jobs in one such person. “And I have often seen companies spend a year or more rebuilding the guts of their product to make it scale better. During this time, product related efforts can languish and feature development takes a back seat.”It can be argued this was Twitter’s 2009 story. They spent so much effort on scaling and were not able to do much on the features side. The basked in the buzz glow, but did not quite ride the buzz wave. ” Teams should be between three and seven people.”I think three is the better number. The last paragraph is powerful.
I agree with you in theory, Fred. But, I’m going to pose you a question: there are several ad network/internet advertising companies in your portfolio. Do you consider them technology companies? Is the role of Prod vs Engineering described applicable to online advertising companies?I wrote a blog post recently called “The awkward role of product management in online advertising network companies” — (http://www.geekmba360.com/a… on this topic. Personally, I have been discouraging product managers from joining ad networks. I think it’s a losing battles for most product managers who work for ad networks.I believe the background of the CEO (i.e. his understanding of role of product management), and business model have a lot to do with how product and engineering roles are structured in a start-up environment.
I can eat a lot of pizza.
As an “old man” I would say this.If you think you can get by with a team that doesn’t have somebody that has built production software….not consulting-ware, not prototypes, not a system that looks nice for VC’s you’re doomed.Then you spend that year in pain. Embrace it, live it, understand it.Even people that have built systems that take 100M bets before the Kentucky Derby or Superbowl have hiccups..And they damn well better have the power to say no….i.e. this is the way we have to do things. If they are the hired help….live the pain.
Agreed. As one in search of the right yin for our yang, strongly believe in a partnership to lead the way. This article offers some examples of some historic, successful partnerships: http://blogs.hbr.org/cs/201…Katherine Warman [email protected]
I only have one question:So how do you train people for product if this is all the case.
I think this is the essence of my question as well, or perhaps the converse?
Converse.A) why framework- I’m an art student- processing and suddenly ruby for me (intro level)? But that may all kind of useless when defining a process.As they say in art school- it’s knowing when to stop so that you will cause a reaction. It may or may not be part of the coding process at all.
As a geek, I resent product people. They think their job is to have the ideas, and our job is to implement them. The thing is, that’s wrong – if anything, geeks are in a far better place to have ideas because they know what’s possible. It’s also far, far easier to stumble upon a technology and say “hey, we could use this in this way” than to have a non-technical person say, “Let’s add a button that reads a users mind. It’s just software, right? Make it happen.”The only potential valuable part of the product role is to help the geeks be consistent and focused on the product ideas they themselves came up with.
Going through this right now. Our VP Tech is strong, but I’ve waited too long to replace myself in the product role. I found that up until about 15-20 people, it was somewhat manageable. After that, it seems to get to the point where a higher level product person is beneficial – if not critical – for future growth.
Oddly, I’m a CTO who once had product reporting to him at a prior place but doesn’t in my current shop. I’d rather be VP of Product than in Engineering — seems like a better path to the top (particularly once you’ve put the CTO notch on your belt). It’s hard in a different way, but I think that CTOs who have a good business orientation are naturals are this. Problem is that it’s difficult to get recruiters and CEOs to see that CTOs can make the leap. There’s this whole chauvinism about product — if it’s staff by tech folks, it must be tactical; the only way it can be strategic is to have it sit in the marketing stack. I say BS, but I keep trying…
Great post Fred. I agree that it’s key that the VP Engineering and the VP Product “need to work well together to build a great company.”I would only add that in the spirit of that statement there is even more collaboration than where you describe what the VP or Product does and what the VP of Engineering do. I play the Product role myself for most products/projects and while I’ll sketch out / write out a high level description of what we are trying to get through, I think of the spec, ui, ux process as a collaborative process where the VP Engineering, as well as the engineers themselves, get to apply their own ideas and creativity to those elements. I’ve found that besides the fact that they usually take a good idea and make it great by their own contributions, that it also enhances their sense of ownership of the project and is more rewarding for their long term satisfaction as engineers. So they’re not just building what I’m telling them to do, we’re working together to accomplish a goal we mutually share and shape.
Agree wholeheartedly with the post as it is at the center of my own current startup’s struggle but also was at the center when I was most recently at a relatively large though shrinking Web Company.Many instances the speed with which each of the distinct roles moves is out of kilter making collaboration difficult at best. I am biased but Tech usually moves faster and has the wherewithal to plug the holes in the product vision or requirements if you are lucky enough to get them in the first place. Doesn’t mean you get anywhere productive with that scenario though as Product often has (or should) a clear understanding of what a potential customer would find useful and that doesn’t come across clearly in most instances from the purely engineering perspective.
Another wonderful post. In addition to the balance between Product and Technology, I increasingly see the need for “Design” at the table, as an equal stakeholder. In my experience, at least in the enterprise space, the SaaS model is moving the needle on technology adoption from the company needs to individual needs, and great design is becoming essential. It’s as hard to retrofit design into a solution as it is to re-architect a platform, but this rarely seems to be the domain of great customer-driven product managers, or of excellent technical leads.
Fred – great post and I agree with it 100%. But, in my experience, it’s not only applicable to tech companies – you could have written this about e-commerce retailers too.To GeekMBA360: Wow. I could not disagree more! Having the Director of Product reporting to the VP of engineering would cause all kinds of problems. You can kiss customer experience goodbye; you can also forget about being responsive to the market; you’d end up building what the engineers want to build. The microanalogy would be a website where developers make all the decisions: Very cool to look at, but impossible to buy anything from it.
Do you feel that this model works for both Software/Online companies as well as a company producing a tangible widget?Are you a proponent of a CDO (Chief Design Officer)?
Indeed. You first need people who know, hopefully naturally, what’s important to remember too. That’s generally why I like to actually verbally hear about their encounters. I can lead a bit then questions to get depth to certain feedback I know to be important.