• Skip to main content
  • Skip to primary sidebar

Teague Hopkins

Mindful Product Management

  • Home
  • About
  • Blog
  • Contact

Management

Mar 07 2014

Your Brain is not as Smart as it Thinks

Why should you care about ego risk? Because risks to innovation and new ventures follow the Pareto principle: only 20% of the risks a startup talks or thinks about are ego risks, but ego risks account for 80% of the challenges they face.

I’ve talked before about the 3 types of risk in new ventures. While tech and market risk get all the fanfare, ego risk is at the heart of most problems startups encounter. If you don’t manage market risk, you will build the wrong thing. If you don’t manage tech risk, you will fail at building that thing. If you don’t manage ego risk, you will fail to build anything at all.

Here’s the kicker: Most startups don’t die because they built the wrong thing. They die because they didn’t build anything.

Creative Commons Credit: LMH on Flickr
Creative Commons Credit: LMH on Flickr

Ego risk encompasses the whole set of challenges of managing ourselves, our teams, and our companies. As a leader in an uncertain venture, there’s no map to follow. With no clear yardstick for gauging success (except at certain rare intervals), managing your personal psychology and the mental health of your team becomes a crucial task, not just to prevent the productivity drop-off at the half-life of enthusiasm, but to avoid falling prey to cognitive biases and misapplied mental heuristics.

We’re all vulnerable to cognitive biases: traps in our thinking that lead us astray. Here are a few to watch out for:

Survivorship Bias – We focus on the startups that made it, and ignore the ones that disappeared before we heard about them. Then we draw conclusions about the whole from that small subset. For example, the startups that we’ve heard of mostly failed because they didn’t build the right thing. We never even hear about the vastly greater number of startups that built nothing. So we erroneously conclude that most startups fail because they build the wrong thing.

Overconfidence Effect – We estimate that we’re right more often than we actually are. We are often 99% certain that our estimates are correct, only to find that 40% of the time, they are wrong. Humans are notoriously bad at predicting the future, and it wreaks havoc on business plans. Entrepreneurs may plan and act as if the future is clear and make large bets when it might be more prudent to start with a smaller bet and wait for confirmation.

Sunk Cost Fallacy – People tend to throw good money after bad when in fact, it doesn’t matter how much we’ve spent: the only thing that should matter is the payoff from the investment we’re considering making – and the opportunity cost of not doing something else with that investment. But if we invest in a plan that doesn’t work out, we are more likely to double down on trying to make it work than to ignore our losses and invest in the best current option.

Availability Heuristic – When something is easy to recall, we think it must be more likely or more common than something that is harder to recall. If the last 2 people you talked to like the color green, you will think that most people seem to like the color green. This can lead us to jump to conclusions about our product or our market, instead of objectively evaluating the reality of people’s preferences and needs.

Confirmation Bias – We see what we want to see more often than it’s actually there. Especially when there is some level of ambiguity, our brains will interpret data to be consistent with our hypothesis, rather than challenge it. This can be dangerous when it causes us to think we have confirmed a theory, and proceed to act on it, when we’ve actually gained no further validation.

Bandwagon Effect – People tend to believe what other people believe. If most of your team believes something to be true, the rest of the team may come to believe the same, regardless of evidence to the contrary. The absence of dissenting opinions can make for a dangerous environment where the whole team moves in one direction without examining whether it is in fact the right strategy.

Halo Effect – We assume that people who have one positive quality must have others as well. One result of the halo effect is that we think that attractive people are correct more often than people who are not conventionally attractive. Just because a founder is good at code doesn’t mean they understand selling – and vice versa: yet another reason to set measurable goals and test against them early and often.

Hindsight Bias – We forget how wrong we were, and underestimate the importance of those first experiments. This is why it is so important to document hypotheses and minimum success criteria.

Dependence of self-concept on success of the business – When the business is failing, it’s common for the founder to feel like they are personally a failure. The countless entrepreneurs who have talked about this usually begin by referencing many of their friends and colleagues who suffer from the same thing, but don’t talk about it. So it’s a pretty reasonable bet that this is universal. Don’t feel bad.

Stay tuned for some tactics that can help you manage ego risk.

Written by Teague Hopkins · Categorized: Main · Tagged: Cognition, Cognitive bias, Critical thinking, Decision theory, ego risk, Intelligence analysis, Lean Startup, Management, Risk

Oct 11 2013

The Secrets of Product Management

I’ve had several conversations recently about the nature of product management and the role of product managers. One thing that kept coming to mind was an old post by Martin Eriksson, which defines the product manager as the person who sits at the intersection of UX, Tech, and Business.

Eriksson says that the role of the product manager is to:

    Image Courtesy of Martin Eriksson
    Image Courtesy of Martin Eriksson
  • assess and articulate the needs of the user,
  • understand business goals and constraints, and
  • communicate requirements and prioritization to the tech team.

That’s a good starting point, but I wanted to add a few things to that description that have come out of my conversations with product managers and the people who work with them.

UX is not UI

It’s been said before, but it bears repeating: user experience is not about the interface. It’s about the complete end-to-end experience of engaging with your company and your product. This is the part where the product manager observes the user and designs experiments to gain more insight, so that they can be the voice of and proxy for the user in internal discussions. Lean startup principles and customer development are two ways of thinking about how to collect those data and insights about what drives your customers. The product manager has to collect that qualitative and quantitative data and make sense of it in the form of a product strategy.

Vision

The product manager holds the overall vision for the product. That person must be able to guide the fine-tuning of the details without losing sight of the bigger picture of what the company is trying to build. Usually, this involves maintaining a product roadmap for internal communication.1 The goal is to help guide the team in the process of creating a high-quality product that achieves that vision without diluting that value. One of the most difficult parts of the product management role is saying no to good ideas. A lot of good ideas don’t add up to a great product. If you’re having trouble with ideas in isolation, try making it a strategic decision by choosing among choices instead of making a series of binary decisions.

All Together Now

The product manager also has an important role in coordinating between the development, design, marketing, and sales teams, as well as accounting and business development. Each of these groups speaks a different language – with different jargon and different salient variables and goals. The product manager is the ultimate cross-cultural communicator, speaking each language and translating among them. Building consensus and coordinating efforts across functions is critical to executing a strategic plan, and the product manager is responsible not only for coming up with the strategy, but also for seeing it through.

Bonus

On teams that use Agile, the product manager sometimes serves as the Product Owner, in the role as proxy for the customer or end user. While insights from the true product owner – the user – are key to setting strategy, the product manager is the one inside the building and available to give clear decisions about murky ideas. Those decisions aren’t necessarily always right, but they help the team avoid analysis paralysis.

One note here: the Scrum Master in Agile is the person who owns the Agile process. The product manager cannot effectively serve as the Scrum Master, because those roles have different priorities that often naturally involve some productive conflict, and that should remain a separate role.

Double Bonus

As the person who can most clearly articulate the problem you’re trying to solve for your customer, your product manager can be a great evangelist for your company. The fact that she has interactions with and an understanding of almost every part of the business is an added benefit. If you have a product manager who is a good public speaker, take advantage of it and put her out there. You will probably see extra benefits from giving her more time “out of the building.”

Product Manager Job Description

This got me thinking: if I was writing a job description for an exceptional product manager, what would I include? The following is my take on the skills needed to excel in this role. Feel free to commandeer this for your own purposes.

Experience with lean startup and customer development. Understand the customer, and not just by asking them what they want.

Ability to influence without authority. Much of the product management role requires coordinating among people who don’t report directly to them. Diplomacy and negotiation is a requirement, not a nice-to-have.

Previous P&L Responsibility – The product manager must understand business to the degree that he can understand the constraints, risks, and tradeoffs, and make educated bets with imperfect information.

Analytics and data – Qualitative data are great, but even more useful when they are not used in a vacuum.

Coaching technical teams – It’s critical that the product manager has some sense of what is easy and what is difficult for developers. Also required: being able to communicate what you want to the team and predict challenges the team might confront.

Technical Background – When you can speak your developer’s language (if not write it), everything goes smoother because you can skip steps by understanding technical limitations and complexities.

 

1. The internal caveat here is key. If you publish the roadmap, customers will see it as a promise instead of a flexible plan.

Written by Teague Hopkins · Categorized: Main · Tagged: Agile, Agile software development, Business, Lean, Lean Startup, Management, Marketing, Product management, Product manager, Project management, Risk, Scrum, Software project management, Systems engineering, Systems engineering process, User

May 02 2013

Ego Risk Downs DC Startup Tixelated

TixelatedIn an article in the Washington Business Journal, Philippe Chetrit speaks candidly about the factors that caused Tixelated to shut its doors.

“What we ran out of first, before ideas, before money, before time, was steam,” [Chetrit] writes. “We spent two years tirelessly working, putting all our time, faith and resources into Tixelated. And what we were getting in return was stress, worry, and emotional haywire.”

This is not a case, as ego risk often is, of cognitive biases tripping up the founding team, but a simple reality that starting a company is hard and our own psychological wellbeing sometimes takes priority over the success of the business. It’s rare to see such open and honest evaluation of the emotional challenges leading to the decision to shut down a business. Kudos, Philippe for being a leader in the conversation on ego risk. We look forward to watching what you do next.

Written by Teague Hopkins · Categorized: Main · Tagged: Business, Critical thinking, ego risk, Management, Risk, Risk management

Apr 14 2013

The Ideal Profile of an Early Adopter

When you’re doing customer development, you are specifically NOT trying to understand and satisfy all of your possible users, or the total addressable market. You can deal with the whole market after you get off the ground, but you’ll never get there unless you understand and satisfy (or better yet, thrill) your early adopters. You need to find the people with your problem who feel it so acutely that they are willing to try your imperfect solution, and to help you see where it needs to be improved. These early customers are worth their weight in gold once you find them. They will be your greatest source of insight into why the product isn’t working, the most supportive when it seems like you’ll never get it right, and your loudest evangelists when you finally nail it.

Portrait of an Early Adopter

Image by Mike Licht, NotionsCapital.com
Image by Mike Licht, NotionsCapital.com

To find people with the problem you’re solving, look for five simple criteria:

  1. They have the problem,
  2. They know they have the problem,
  3. EITHER they are paying for a solution currently
  4. OR they have hacked their own together,
  5. AND they are still unsatisfied.

If you’re talking to people who don’t meet all of these criteria, they are probably not your early adopters. They might be future customers. They might think they’ll buy your product at some future point, but that point may never come. If they aren’t willing to buy until the product is perfect, you can’t afford to focus on building the product just for them. Keep looking until you find the people who need your solution so badly they will climb on board with you before you’ve finished building the boat.

Written by Teague Hopkins · Categorized: Main · Tagged: Business, Customer, Customer Development, Early adopter, Lean Startup, Management, Marketing, Product management

Feb 22 2013

Interview with Elliot Susel: Tech Risk + Agile

An interview with Agile expert Elliot Susel about using agile to mitigate tech risk.

Full Transcript

Teague Hopkins: Welcome. I’m Teague Hopkins. Today I’m here with Elliot Susel, the senior project manager and primary Agile evangelist for Taxi Magic, an app that helps people book ground transportation. Elliot’s an expert on Agile has worked on it for five years at Accenture and now you’re at Taxi Magic. Is that right?

Elliot Susel: That’s right.

Teague: To start off, what is Agile for people who are not familiar with it?

Elliot: The core idea behind Agile is a series of practices that help you to develop software iteratively. That’s the core idea behind the Agile methodology.

Teague: For some of our entrepreneur listeners, how can Agile help ameliorate tech risk, this idea that we’ve talked about as the challenge of whether we can actually build the things that we’re trying to build?

Elliot: As you’re working toward a technical solution there’s a number of tools from the Agile methodology that you can use to help you work iteratively and to work your way toward a solution rather than having some grand vision and being unable to test that vision until you’ve got this final product and it may fall on its face. The idea is that by having value that you can deliver incrementally by using Agile processes and working iteratively you can test your assumptions as you move along and then also refine your ideas. As it relates to technology specifically, there’s a couple things that you can start to accelerate by working iteratively. The first is that not only are you able to improve the product, you’re also able to improve the team that’s working on the product. So, one of the core Agile practices is this idea of a retrospective where the team talks about what’s going well, what’s not going well, and specific actions that we can do to improve in the future.

Teague: I know that you’ve got a couple of retrospectives that you use on a regular basis. Can you explain what your favorite one is and how it works?

Elliot: Yeah. One of the favorite retrospectives that I’ve ever done was oriented towards gaming and I said, we can make this retrospective not just an exercise where we make some columns on a whiteboard and say here’s what we liked, and here’s what we didn’t like, but we could get really creative. So, we turned it into this game where you would draw on the whiteboard anything that would accelerate us, and you would draw on the whiteboard anything that would impede us, and we were represented as a ship in the ocean. We ended up with giant squid, and fire-breathing monsters, and anchors, and airplanes, and sails, and party cakes, and all kinds of representations, and

Teague: And that still helped you get towards the goal you were getting at?

Elliot: Each one was not just a fun thing to draw, but also had with it an association. I think that the giant squid had to do with our testing, and the team then had to figure out well how do we solve this issue of testing and then they also drew something in to deal with the giant squid which was a fun exercise.

Teague: Great.

Elliot: It kept it light-hearted and it got everyone really engaged.

Teague: Uh huh. (affirmative) It sounds like a lot of this idea of working on the technology in an iterative way sort of dovetails with a lot of the Lean startup methodologies. In your experience have you seen any byplay there?

Elliot: I would say yes and no. You can do Agile without being Lean, which is unfortunate, but I would say that there’s really three roles on an Agile team. One role is the product person, the product owner more formally, where their vision and their goal is to set the vision for the team and define what the team should be building. Now a product owner may or may not be working according to Lean principles and can march the team in a direction that may or may not be consistent with Lean. There’s the scrum master whose job it is to remove impediments and to help the team move as quickly as possible.

Teague: Uh huh. (affirmative)

Elliot: And, the team whose job is ultimately to be in the iteration.

Teague: Uh huh. (affirmative)

Elliot: And the more time they spend in the iteration and not on distractions, the better.

Teague: If you were talking to somebody who’s adopting Agile for the first time or trying to adopt Agile for the first time, what would be the most important piece of advice you can give them in terms of taking their first steps?

Elliot: Find a really good coach. Find the best possible practitioner that you can actually spend time with. And, to use the words of the scrum master and practitioner that I learned from, to spend time in their dojo.

Teague: Uh huh. (affirmative)

Elliot: A scrum master really is creating an environment and it’s not just this series of practices; although the practices are important, but it’s an organizational mindset where yes the team can build incrementally and that’s lovely and that mitigates your tech risk. But, also, it helps if the product team is also thinking incrementally and how can we test our assumptions incrementally, and how can we incrementally work toward our solution in the best possible way?

Teague: Excellent. Well, thanks, Elliot, for joining us today. You can find out more about Agile, and Elliot, and Taxi Magic at Elliot’s website at www.elliotsusel.com. Thanks for listening.

This interview originally appeared in The Three Biggest Risks to Your Startup.

Written by Teague Hopkins · Categorized: Main · Tagged: Agile, Agile software development, Business, Lean, Lean Startup, Management, Project management, Risk, Scrum, Software development, Software development process, Software engineering, Software project management, Technology

  • Page 1
  • Page 2
  • Go to Next Page »

Primary Sidebar

Copyright © 2025 Teague Hopkins
 

Loading Comments...