Profitability / growth expectations and the $100 million base hit.

Kevin Gao of Hyperink on why VCs don’t generally see dollar signs / hear jackpot noises over content based tech businesses.

When did a $100 million dollar business become a “base hit” and something one has to be “OK” with? While that’s not the sum of the points made and I’m not trying to harp on a straw man argument, something about the sentiment touches a sustainability nerve for me – growth for growth’s sake, Apple-sized market caps / valuations being the only indicators of performance. Obviously that’s what capital markets are about, the post is on Silicon Valley VC funding, and Gao later states it doesn’t need to be your goal. Besides, Hyperink seems to have a business model based on medium form priced content aimed at the long tail.

But I think the sentiment reflects the mindset that seems to pervade the tech-business scene, at least around the Valley – who will be the next boy king of the universe? It downplays the fact that there are many more businesses that make up a larger part of the economy that won’t ever see cancer like growth quarter over quarter or have “Pan-Galactic Domination” as the goal line. And they still manage to make their customers and owners happy in terms of problems solved and reasonable returns.

More power to building the next ten bagger if that’s the exit goal – but to extend the metaphor, having Ted Williams’ batting average connecting on solid base hits isn’t exactly bush league performance. With the meltdowns we’ve seen twice in the past 12 years, building something meaningful and sustainable isn’t a business goal that must be accepted with resignation.

First things first: What you should do when starting a new product management job?

My response to this question on Quora got some buzz so I thought I’d elaborate on it here. Far be it from me to ignore market demand.

1. Understand “why” first:

Do not prescribe before you diagnose. Remember that people are not stupid to have done as they have. They know more than you about the specific problems the organization has faced, have been working them longer and there are reasons why particular decisions were made. Your first goal should be “5 whys” on relevant issues before telling people “what” you think needs to be done.

Among my friends, we have a joke about ISO registration for people – granted based on whether you consistently do what you say you’re going to do. I firmly believe this is the functional basis of trust.

Kouzes agrees in Credibility, defining credibility in behaviour as doing what you say you will do. Credibility as a leader is then doing what we say we will do, since leaders represent the people they serve in common goals. Credibility is further defined by Kouzes as the product of values, competence, confidence, vision and honesty.

How is this relevant to starting a new product management position? You need to establish credibility with your new colleagues. Be clear on your values as a product manager / leader as this will guide your decisions and actions. What are the most important things you want the product to do for people?

Regarding competence, you may know what to do and how to do it from experience (you got the job didn’t you?), but an understanding of the current context is needed before anyone starts waving hands / chainsaws / megaphones around on vision and plans. You may be confident in your ability to solve problems, but that has to be applied to specific domain / subject matter expertise. And if you’re not honest about any of these initial gaps, no one will see you as credible.

As Josh Schwarzapel put well in the Quora thread, nothing will marginalize you faster than being bold and wrong early on. I tend to agree with the Eddie Obeng’s idea that if dealing with unknowns, you want to fail as fast as possible and iterate off that, but if dealing with known, failure is not acceptable. So better to listen first, figure out what works and what doesn’t, then pick the right next battle instead of coming in guns blazing. Any fool can regurgitate how things should be based on a cursory understanding of best practices. Experienced leaders know that ideas and words are cheap, knowing how to engineer meaningful changes in a professional manner is what they’re paid for.

2. Understand the complete business model, strategy and how current processes work.

Map out a one page canvas to take a big picture snapshot of the business model and strategy. Then find out how day to day processes work for that strategy, like release planning, customer feedback capture, development execution, sales and support.

Every data point could be a potential area of contribution as a product leader. Next level innovation in product management isn’t just on the product or features but the entire business model. Think about how you can own and engineer positive improvements across the board. Doing something different and valuable in each of these canvas areas yields creates competitive advantages beyond features that can be bought or copied. Some companies have done quite well for themselves doing something very innovative and valuable in just one major area of their business model while the rest is somewhat similar to other competitors.

Here’s Alex Osterwalder of the above linked canvas talking about this approach as well as John Mullins of Getting to Plan B getting at the same idea. Ash Maurya also applies this type of thinking in Running Lean, which I’ll be talking about in another post.

3. Become the market expert to development. 

This is achieved by gaining outside-in experience actually talking to customers. Get out of the office as Steve Blank puts it so well. It is fairly easy to pitch meetings as a new product manager needing to understand customers, but just find a way no matter what – it’s the cornerstone contribution of the role. Understand the market problems you’re out to solve and how they can be solved otherwise. Be able to drop names and quotes on customer pain. Sit in silently on sales presentations to hear how market problems and messaging are being done. You can ask others for their views on value propositions and messaging to target markets, but don’t breathe internal fumes more than you test ideas against outside feedback and form your own thoughts – you’re supposed to be the expert.

4. Become the product expert to sales and marketing. 

You should be able to demo within 15-30 days of starting and have made your own outward facing materials in the meantime – videos, presentations, elevator pitches, etc. Given the market data collection above, you should be able to explain better than anyone else why people throw money at your product. Be the go-to person who can answer tough product questions in presentations that stump others. Go through both the existing product backlog and bug list to understand each item. Rewrite stories / requirements to a consistent standard (e.g. based on personas and themes) as an activity if it helps. Set up lunch and learns with the product team and respective functional subject matter experts. Sit in on support calls to understand customer problems. Use the product and read the documentation, trying to solve the same problems as customers. It’s not rocket surgery – become an expert on the “product” part of product manager.

5. Develop a 30-60-90 day plan for what you need to deliver with your boss and other key stakeholders.

Senior management, heads of the different functional areas, development teams, sales and partner channels – your job is to serve these different stakeholders for the product you lead. Define the hypotheses you want to test and how success will be measured then the experiments and activities to get there. Some areas to consider:

  • Customer Lifecycle / Sales Pipeline: Acquisition-Activation-Retention-Revenue conversion for web products, Funnel analysis for enterprise deals, Win / Loss Analysis for either
  • Development: User Stories / specific features to be built, quantitative and qualitative acceptance criteria for quality assurance, reviews against requirements, team performance (although this is more development management, you know product management is doing their job if there is less thrash and uncertainty in the team)
  • Release Management: Roadmaps, release ship dates and milestones within releases. Some agile shops don’t believe in roadmaps but every place needs a prioritized plan for what’s next.
  • New Product Introduction: Interviews to test risks in all canvas areas (e.g. problem-solution) Minimum Viable Product and Reference Customers
  • Existing Product Improvement: Quantitative profitability and A/B cohort analyses, support tickets / bugs, feature overhauls, performance benchmarks like load/process times
  • Customer Satisfaction: Net Promoter Score, usage frequency / depth / breadth assessments like Customer Happiness Index
  • Direct Customer Use: reports, dashboards and analytics for customers on their data

6. Establish critical relationships with representatives from the relevant functional areas. 

You should know who to ask on particular subjects as well as be seen as the go-to / directly responsible individual for the products(s) you’re leading. I agree with Marissa Meyer’s statement that as a product manager you don’t have all the answers, but you work with others find them. Become a broker in answers and lead cross-functional problem solving. As a product leader, answers and solutions ultimately come from people and the relationships you have with them.

Making things that kick ass and don’t just suck less: Self Determination Theory and Product Design / Leadership.

I’m a fan of elegantly simple but powerful explanatory models. As far as that combo goes, Self Determination Theory is one of the better ones I’ve come across, and can be used as a guiding framework in product design and leadership.

Kathy Sierra succinctly (and in more depth) made the point that product design shouldn’t just be about making a better feature X, but making a better user of X. The design objective should be to “reverse engineer user awesomeness”.

As a product leader, it’s more exciting to build things that kick ass and don’t just suck less than the alternatives. Self Determination Theory is a means of thinking about and achieving that end.

Self Determination Theory – Key Takeaways:

Self Determination Theory is a basic model for human motivation. It positions that we all have the same fundamental drivers in what we do:

  • Autonomy: People want to agree with what they do.
  • Competence: People want to master meaningful things.
  • Relatedness: People want to be connected to those around them.

Daniel Pink addresses Self Determination Theory in his book “Drive”, as does Cal Newport in this post. See RSA Animate’s video or Pink’s TED presentation:

This may be intolerably fluffy for technical types, but it simplifies some of the drivers that make people want to come into work or give you money for the things you make. If you want to create something that matters, it’s your job as a product leader to figure out the business and psychological drivers in your customers and colleagues.

Maximizing Autonomy in Design:

When you’re creating a design, does it force decisions on the user or give them the choices they need? Some solutions limit options and flexibility – which is fine if you actually nail the solution perfectly, but aggravating if you don’t. Simplicity is a sign of real understanding, but often restrictive designs are the result of inadequate consideration rather than genius insight. Design for intermediatesas simple as can be but no simpler.

Will users agree with the solution as the best way to solve the problem? In design, often regurgitated rationalizations of “you don’t know what you’re talking about” are Henry Ford’s line on faster horses or Steve Jobs’ on users not knowing what they want. That while domain and problem expertise may be high, it’s not up to users to know the best solution, since they don’t have the same command over technical possibilities that you should as a solution maker.

Which again is fine – but if you’ve really nailed the solution and understand the problems you’re serving, people will ultimately agree to the approach as being better than what they had in mind or currently use. I have found this true even when proposing solutions to engineers, who pride themselves professionally on not needing others to tell them how to fix things. This should be the goal line – buy-in on decisions rather than imposing them.

Does the solution give back freedom and control over how people spend their time? It should lead to better living through technology compared to other options. Users don’t care about the technological means as much as the practical ends they achieve. Time is a finite resource for everyone, money is not as finite – money can be replaced, but you can’t buy back the 1440 minutes of your day. The more time you can give back to people to spend how they wish, the more powerful and valuable the solution will be in their lives, the more money they’ll be willing to give you for that.

Maximizing Competence in Design:

If you look at the most effective technology solutions, they tend to have what Alan Cooper characterized as the personality of a smart and helpful colleague. Put somewhat differently, they’re not assholes – they don’t make it hard for you to get help or solve problems. They provide the right level of support needed for the job when you need it – more or less is equally annoying. They help you accomplish more than you could have on your own or with other methods.

Does the solution turn the user into a superhero, or does it make them feel stupid and incompetent? Equally, does it condescend their level of understanding by treating them like an idiot?

Does the design naturally build on what the user knows and how they see the world in terms of mental models and technical skills? Or does it force them to have to absorb a lot of unnatural, illogical and boring crap before they can actually start kicking some ass? Build solutions to people rather than the other way around. Don’t make them think, if possible.

Does the solution help the user do the things that matter in their job and advance them to where they want to be? If you’ve done your job effectively, users will be able to do theirs easier and faster and then move onto better. If you haven’t done this, someone else has a shot at ripping and replacing what you do. Solution allegiance is limited by self interest.

Maximizing Relatedness in Design:

This is more than just putting a Like button in the solution or making it easier to creep on coworkers. No endeavor of any significance is accomplished in a vacuum from other people or ideas. Steven Johnson made a compelling case that every major innovation in the past 600 years really has come from people and ideas getting mashed up like a Danger Mouse mix rather than one ubermensch working alone by candlelight, struck in the head by a bolt of lightning.

Does the solution help users connect and build something greater together than they could have on their own? Does it put up walls or create networked connections to knowledge and abilities? Do users have to recreate the wheel each time they do a task, or can they take advantage of all the people and work that came before them?

B2B executives often talk about leveraging an enterprise repository of best practices to standardize performance, and one of the most enabling uses of technology is to make knowledge available where it wasn’t before. Plagiarism aside, think about how students went about writing research papers prior to the advent of Wikipedia and Google. Don’t make the technological equivalent of having to trudge to the library or consult the one guru on the subject living at the top of a mountain if they can connect to people and answers from their laptop and dorm room.

   Apu: He is the benevolent and enlightened president and C.E.O. of
        Kwik-E-Mart -- and in Ohio, Stop-O-Mart.  He is the one we must
        ask for my job back.
Master: Approach, my sons.  [they do] You may ask me three questions.
   Apu: That's great, because all I need is one --
 Homer: Are you _really_ the head of the Kwik-E-Mart?
Master: Yes.
 Homer: Really?
Master: Yes.
 Homer: You?
Master: Yes.  I hope this has been enlightening for you.
   Apu: But I must --
Master: Thank you, come again.
   Apu: But --
Master: Thank you, come again.

Mary Meeker’s brain dump or the fact that Facebook is focusing more on mobile than desktop these days should underscore the importance of enabling access to knowledge and people across contexts. It’s not the device per se but ubiquitous connection that matters.

How easy does the solution make it for people to stay in the loop with what’s going on? After you start to warehouse data or activity of any type, the very next things senior executives ask for are reports / dashboards / analytics on that information, the ability to drill down on what’s going on or see the big picture. A big deal is made of analyzing big data and advertising hearts are aflutter about all the personal information now available for targeting. Are you providing similarly powerful insights into the people and relationships in your solution?

I’m not suggesting going all Big Brother here – as anyone who has sold a CRM solution knows, users (sales) don’t want to use anything that contributes to that end, even if their managers love it. But ideally you should make it easier for people to relate and connect than they could before – think more of the viral engine of growth Eric Ries calls out, where user adoption and connections increase just by people using the solution for their own interests.

Does the solution help give recognition and respect for the work people do, or does it make them more invisible? Given the choice, people want their work to be meaningful to peers, superiors and those they serve. A simple thanks or shout out can be enabled technologically as well as through conscientious management style, and increasingly you are seeing technology solutions for socially reinforcing desired behaviors in business, like the one from Achievers. People post what gets liked on Facebook and LinkedIn, voted up on Reddit and Quora – make it happen at work beyond relying upon a manager’s predilections for giving praise and thanks.

Maximizing Autonomy, Competence and Relatedness in Product Leadership:

As a basic model of human motivation, obviously SDT also applies to how you can relate to your colleagues when making stuff, not just your customers.

Do you treat colleagues as trusted advisors, respective subject matter experts, show respect for their autonomy and competence in the way you work with them? Do you impose decisions and viewpoints or help people feel ownership and involvement over what happens? How often do you preface product design decisions with “I” vs. “We”? Is the sum of all relevant expertise contained in your decisions and designs? Do you give out recognition and respect to those who deliver, or does it go unnoticed?

Sometimes people point to Steve Jobs and being the center of the Panopticon as the way to go about making remarkable products. And certainly there are times when a CAPCOM approach helps avoid making a camel. But anyone who has actually built something with other human beings knows you often have to relate to and accommodate specific interests in order to achieve a bigger goal. Nobody with any talent or intelligence wants to work in a unidirectional exchange for very long, and you’re never going to get the best out of people that way.

If you want to make things that kick ass and don’t just suck less, think about how you can maximize autonomy, competence and relatedness – both in the solutions you make and the work you do with others to make them.

Building things to Clarke's Third Law.