Thursday, September 24, 2009

What does Product Management need from Engineering

Yesterday while at lunch I was asked by a VP of Engineering what Product Management expected from Engineering. An excellent question and one that is valid no matter what the organization size - and not as easy to answer as I thought. The definition of product management (and engineering) is different from organization to organization and from person to person - and every organization has different needs, strengths and weaknesses.

The first goal of a Product leader is to create a common understanding with engineering on roles and responsibilities. Don't assume when you turn up that everyone knows what you should be doing (even the CEO). Start with the job description, and sit down and interview all the stakeholders - you'll always find a broad range of definitions and understanding. There is nothing worse than a Product Manager who waltzes into an organization and suddenly expects everyone to follow their definition of Product Management.

A mandatory pre-read to this article is Marty Cagan's excellent article "Moving from Engineering to Product Management", explaining the key differences in thinking between the two roles. I won't repeat those here, but this is extremely important.

The best products are built by a team of engineers and product people who trust each other and interact closely and regularly - there is absolutely no doubt in my mind or experience that a one sided approach leads to failure (or a failure to capture the full opportunity). Interacting with the market, customers, partners, analysts, press, developing product plans is a full time job. Ditto building software.

Keeping that in mind, here's how I answered the VP of Engineering's question:
  1. The number one goal is for PM and Engineering to form an open and trusted relationship and nothing else matters. The groups must be talking every day and feel that they can rely on each other and trust the other to do their job. Although this sounds simple, it's often neglected. Communication must occur in person and a good model to follow is the agile "15 minute standup". If frequent and open contact does not happen then the relationship is doomed - at one role of mine the CEO was almost continually unavailable, so I was never able to really connect and understand what was needed/wanted.
  2. Conversations must be open and honest - each side are smart and have an ability to detect bullshit. There is nothing wrong with admitting shortcomings, concerns, resourcing issues, etc. I have noticed in the past that it may take a "blow up" i.e. emotional argument to reach a point of openness - I am not advocating this as a path, but it has worked for me when we didn't seem to be making progress in the day to day meetings.
  3. There needs to be a recognition from Engineering that Product and Market issues cannot be solved the same way as engineering problems. Engineering is analytical and technical discussions can be debated in precise terms and solved in an absolute way. Market issues are a complex mix of data, market forces, customer desires, economic conditions, positioning, pricing etc. I have seem a lot of conflict between Engineering and PM when Engineering continually pushes and frustrates PM for "more data" even though decisions are made with a different set of criteria.
  4. In a similar vein to above, Engineering needs to understand that we are living in an extremely fast moving and dynamic world, and in the worse recession for 70 years. Product can do all the right work to decide a future direction, but the ultimate approach that all companies must take is one of Product Discovery (another blog post of its own). You must get to market quickly and validate the path is correct. There is no shame in ackowledging that all the right work was done, but after the first iteration the market has moved or you missed the mark - the main thing is that you can understand what changed, and refocus quickly. So Engineering needs to not show frustration to course changes along the way, and not blame PM.
  5. When the above occurs we can reach the ultimate point - Engineering and PM see themselves as joint stakeholders in the product. No one group owns it or takes credit, and each team is confident that they have part of a successful team, and when PM asks for changes they do it for good reason.
The above has focused on relationships, frames of mind, and reaching a mutual understanding, because once that happens, everything else can be solved. From a nuts and bolts perspective, here are some of the things that PM would expect from engineering:
  1. Requests for clarification or additional information on products, MRDs, uses cases, etc
  2. Status updates on projects - what is on time, what is behind, what needs more resources
  3. Feedback on support issues - how much time are they consuming, trends etc
  4. Feedback on any customer issues or opportunities uncovered directly - engineering is often in customer calls or conferences that can be fed back to PM
  5. Exciting innovations that engineering has produced or could produce
  6. Information on new features and products so that Marketing and sales can be fully briefed on how to take to market
  7. Collaboration on roadmaps
  8. Collaboration on product releases
  9. High level product design and user interaction reviews, so PM can understand if the design will grok with customers.
  10. And finally, don't let issues fester - sit down and discuss concerns early and get them solved before things blow out of all proportion.
The next post will cover what Engineering should expect from Product...

An evening with Larry Ellison

On Monday this week the Churchill Club organized an evening discussion with Larry Ellison, held at the San Jose Fairmont. Larry has been CEO of Oracle Corporation for the past 32 years, since founding it with two other guys and an initial stake of $2000.

Larry came across as an extremely articulate, passionate and driven individual. He seemed quite relaxed, and there was none of the "arrogance" that he is famous for - although I am convinced that many confuse passion and a drive to win with arrogance.

The evening was not as probing or informative as I had hoped, but there were a few pearls of wisdom:

On Competition

I can't remember his exact words, but they were something like "be careful when selecting your enemies, because you'll end up looking like them". To me this was extremely profound - he mentioned that Microsoft is now really focused in the consumer space, likely because they see Apple as their biggest competitor (e.g. Zune to meet iPOD). But Microsoft made their money in the Enterprise, and should they be focusing away from that core strength?

Novell hated Microsoft so much in the 90s that they tried to assemble a company almost identical (remember DR DOS?), and as we know, that almost killed them (although it's been a long lingering death). Novell could have been Cisco, but they focused so much on being Microsoft that they were blind to bigger opportunities.

I got the impression that Larry sees his biggest competition as IBM, especially the IBM of "Thomas Watson Junior". He talked about them in very respectful terms many times, especially how they were able to deliver a complete solution. So another takeaway here is that it's OK to respect the competition.

On the economy

Larry sees the recover as being "L" shaped i.e. he sees a very long recovery, and predicted things won't be getting better for five years. The past boom as based on unsustainable debt driven spending, and we need to return to higher house hold savings. There was also a discussion that the US may need to implement tariffs to combat goods produced where energy is much cheaper (and dirtier).

On Product vs Solutions

The discussion I enjoyed the most was where Larry described the IT industry as reaching a point of maturity (like aerospace), where it will be dominated by 5 or so companies that provide complete solutions. He believes strongly that the past approach of a horizontal environment where the customer integrated the solution was wrong, and we need to return to the IBM model of old where a company delivers a complete working solution.

I personally believe very strongly in the need to vertically integrate, even at the portfolio level, rather than stretching out horizontally. And at the company level, Apple and RIM have shown that a complete vertical solution can function without significant integration issues or costs. If you think about the core message of the Apple versus PC advertisements, it's really all about vertical integration versus a horizontal solution that must be integrated by the buyer.

A final word

On the prophetic words was his advice to startup entrepreneurs to look outside the maturing IT industry if they want to have a shot at building another Oracle. He felt that Biotechnology in particular offered much more opportunities, given the early stage of that market. Sobering words for entrepreneurs.

Friday, September 18, 2009

Incredible, Amazing, Awesome

This video is a funny take on the enthusiasm from Apple executive presenters. It's certainly important to have enthusiasm for your products, but it can sometimes come across as over the top - but remember these words are delivered to an audience of Apple devotees.

I admire Apple and they're got some great products, but what they have created is a religion where they are the deity and can do no wrong. Apple disciples embrace everything Apple, and diss anything not-apple (especially the Satanic company in Redmond). Apple is a phenomenal MARKETING company as well as technology company.

And let's not forget that their primary goal in life is to make (gasp) money for their shareholders. To see people lining up at the company store to pay money for expensive merchandise that advertises your company is truly marketing genius.

I found this funny comment on Youtube by TaxMachina, responding to criticisms of the video:

Will you Mac fanboys shut the hell up? Your rabid attacks and pathetic apologistic reasoning is so much like zealots defending their religion that it is truly sickening. For pity's sake just stop hating for five seconds and look at yourselves.

The video is funny. It is pointing out bad speaking skills not bad products. If you think that EVEN THIS is an attack against your precious precious consumer electronics than you are seriously sick in the head.

Sunday, September 6, 2009

Optimize your Lead Flow Process

Almost all businesses today rely on their public web site to generate solid sales leads, and much of their marketing is focused on driving prospects to the web site. I work with many companies who are pushing their Marketing teams hard for more incoming leads, but haven't taken the steps to optimize the efficiency of how these leads are processed.

An analogy - your lead funnel has a certain efficiency of "raw leads in" to "qualified leads out". This can be compared to the efficiency of a motor vehicle in miles per gallon (MPG). If you need to drive a certain distance (qualified leads), you'll need more gas (raw leads) with a gas guzzler than with a fuel efficient vehicle. Traveling 100miles in a Hummer takes 7 gallons of gas, but a Prius takes 2 gallons. Which one would you rather drive? So instead of telling marketing you need another "1000" new raw leads every day", why not optimize the process and get more qualified leads out.

All companies have an event that they work towards on the web site (and track through systems like Google Analytics) - for IT companies it is generally an evaluation, but it may be a sales contact, reseller request, online purchase, etc. Whether you sell software or hardware products you must focus on a complete understanding of what a customer does to reach the "request point". For the rest of this article I am going assume that we're working towards a product evaluation.

The place to start is a series of customer interviews to understand what problem they are solving, how they found your web site, and what they needed to evaluate. Everyone has customer advocates who want to help - interview these people and if possible video tape them to show to engineering and other stakeholders.

Design your product to have a mode to make for an easy evaluation, and specifically turn off or hide advanced functionality that complicates the process. Riverbed is recognized as a the leader in WAN Optimization appliances, and are well known for winning evaluations - their box is designed to drop into a customer network and "just work".

If a product is extremely complex to evaluate or takes a lot of time, your sales force may not want the customer to evaluate, in order to prevent deals slowing down. Sales are trying to meet their quarterly quotas, and will do what is needed, including avoiding a lengthy evaluation of a very complex or difficult product. This is what I would do in their shoes - Sales has an extremely difficult job, and the last thing they need is to bog deals down, especially near the end of the quarter.

What we really need is a deliverable that is specifically targeted at the evaluator, is easy to install and evaluate, and does not slow deals down. A package that can be evaluated quickly changes opinions. As previously discussed, Riverbed has designed their product to be very evaluation friendly (unlike other WANOpt products), so the Riverbed sales team can push for an onsite evaluation, knowing that they will perform well (and likely win the deal). The Riverbed eval simplicity has actually become one of their key differentiators.

Here are some things to consider whaen designing products for evaluations:

1. Make an install mode for your product aimed at evaluators. Hide all advanced, risky, and/or complex functionality. Turn off features that may be easily misunderstood, or could cause problems in the customer network (you can leave these capabilities under the advanced menu if needed). For an excellent example of how BMW simplified the process configuring their m5 sports check out this segment from Top Gear - it takes some time, but notice the complaints from Jeremy until he finds the "M Button" - (does your product have an "M Button"?).

2. Provide a document to step a customer through a typical evaluation. This is also invaluable for channel partners, press and analysts to review your offering.

3. If your product is hardware based and/or expensive and difficult to evaluate, take a prospect through other steps on the web site before the evaluation request is fulfilled. YouTube videos of the product being installed and used are very valuable, but don't forget product documentation, white papers and customer success stories. All of this can be extremely useful.

4. Don't necessarily ignore leads with "non-corporate" email addresses like GMail. Many corporate staff setup personal email accounts to request evaluations as they specifically don't want to be contacted by a sales person (I do this myself, and I brief survey of my technical friends uncovered quite a few others.

5. If you are concerned about piracy, and don't have the licensing mechanisms to prevent, don't deliver full functionality. Hold something back from the evaluation so that the potential customer must purchase to put into production.

Finally, we live in a world where people want instant gratification. When they ask for an evaluation send them the link to the software, documentation, YouTube videos etc immediately. Show them that you have received their request, and then follow up during the process to offer support, direct to resellers or sales people. There is nothing that turns potentially customers off more than not replying to their requests.

So next time Marketing is pounded to increase the number of raw leads, check whether you have an efficient lead flow process, or do you need to retire the current "gas guzzler" and drive a Prius?