Tag: product management

  • Distribution in digital products

    Distribution in digital products

    This was a great story about how Google’s search distribution deal dramatically increased cost of entry for Neeva, a putative competitor.

    This also reminded me of the Monster/AB InBev deal mentioned in “The Little Book that Builds Wealth:”

    To be fair, it is occasionally possible to take the success of a blockbuster product or service and leverage it into an economic moat. Look at Hansen Natural, which markets the Monster brand of energy drinks that surged onto the market in the early part of this decade. Rather than resting on its laurels, Hansen used Monster’s success to secure a long-term distribution agreement with beverage giant Anheuser-Busch, giving it an advantage over competitors in the energy-drink market.

    Anyone who wants to compete with Monster now has to overcome Hansen’s distribution advantage. Is this impossible to do? Of course not, because Pepsi and Coke have their own distribution networks. But it does help protect Hansen’s profit stream by making it harder for the next upstart energy drink to get in front of consumers, and that’s the essence of an economic moat.

    Once you find product-market fit you need to quickly scale distribution to own as much of the market as possible and preempt new entrants.

  • What I Learned from Interviewing 85 Product Manager Candidates in 18 Months

    What I Learned from Interviewing 85 Product Manager Candidates in 18 Months

    This post was originally published on Inside Q4, stories and lessons learned from the Q4 Inc. R&D team.

    The requirement was extreme: hire 15 Product Managers (and one Director of Product) in the next year and a half.

    When I arrived at Q4 in October of 2021, we were entering a period of hyper-growth in Product Design, Engineering and Product Management. We had huge ambitions and needed to scale our team — fast. I had hired talent before and had conducted dozens of interviews in my career, but the task ahead of me was daunting. As a new hire myself, Q4 was a domain that was still fairly new to me. Plus, the company serves a specialized clientele and isn’t exactly a household name — and the job market is insanely competitive!

    With the help of our CTO, my peers, our amazing talent acquisition team and under the guidance of our inspirational and very applicable company values (Grind, Hustle, Iterate, Compete, Care), we reached our goal. Here are some of the things that I learned as the hiring manager on this assignment.

    Cross-optimize your Hiring Process for Speed and Fairness

    Hiring is a flow, not a project. The point is to run candidates through a process and hire quality, diverse candidates in a fair and equal way as fast as possible — but no faster. Go in expecting that it will take time and unsexy work to do it well, but it will all pay off in the end.

    Create a process: align on it, refine it, repeat

    • Write a good job description for each role; ensure that all the interviewers know what’s in it. A good job description can help turn a mediocre interviewer into an amazing one.
    • Write a good rubric (‘marking key’) for the interviews and take care to set it up properly in your applicant tracking system. Refine it between searches so that you’re constantly applying what you learn in a hiring round to make your process better.
    • Learn from your mistakes! When you have a mis-hire — and we had a few — take another look at your questions, process, and rubric and improve on it for next time.

    Optimize for speed:

    • Have a well-defined interview process for each role, with backup interviewers on call to be added to an interview loop within a day’s notice to keep the process flowing.
    • Use your application tracking system and hold up your end by entering feedback immediately after the interview. This allows your talent acquisition partner to move right into the next step with a candidate (setting up next interviews, generating offers, closing, etc.)
    • Have a fast, scheduled window of time for interviewers to align on a candidate (if needed) and resolve any conflicting hiring decisions. For example, in the case where three interviewers rate a candidate “hire” and one rates the same candidate as “no hire,” use this window to quickly come to consensus.
    • Make it easy for talent acquisition and candidates to book your calendar — Calendly, or Google Calendar Appointment Windows, are great tools to keep all necessary parties organized.
    • Follow up with candidates quickly — especially when an offer goes out!

    Optimize for fairness:

    • Build a question bank! Over the years, I have tried to document every interview I’ve been in as a candidate. That includes writing down any really good questions that I was asked. Good artists copy, great artists steal.
    • Have a consistent process, scoring rubric, skills criteria and question bank that all interviewers can draw on, so that each candidate has the same experience and opportunity.
    • Write. Things. Down. I try to fully transcribe every interview I conduct so that if I need to go to bat for a candidate — or reject a candidate — I can go back to the specifics and have a fruitful conversation with the other interviewers based on facts, not memory or impression.
    • Manage the flow of feedback between interviewers such that you don’t bias each other, but can still use subsequent rounds of interviews to fill gaps in understanding.
    • Create a great applicant experience. Get back to people quickly!

    Never stop recruiting

    Always be thinking about where a good person could fit with your team in the future. Circumstances change often, and quickly, so don’t ever assume the team you have today is the one you’ll have tomorrow.

    • Go back to the well: Past interviews, past applicants, and people who got an offer in the past but declined, are a good source of candidates for future hiring; mine your applicant tracking system for candidate “gold” you may have missed last time around.
    • Do your own outreach: Like us, you may have a strong talent acquisition team, but you’re the one with the in-role expertise. Buy and expense a LinkedIn premium account and send InMail to people you think could be a fit in the near future.
    • Do informational interviews: 15 minutes of your time is worth it if you can meet and nurture a potential future candidate. Team building is a marathon, not a sprint. The older I get, the more I enjoy, appreciate and learn from folks who are just starting out as PM. If a person is too junior today they may be a fit for a new role in six months, or a more senior role in 18. Build your rolodex: the value of this investment compounds over time.
    • Know (and love) your external recruiters: I was brought into Q4 by a top-shelf recruiter who had carefully built a relationship with our CTO over years and has turned into a trusted resource and advisor to me, too. He touches base every four or five months, we catch up briefly, he gives me a read on the market and periodically brings me amazing candidates. Relationships like this propel careers.
    • Focus on team composition, not “fit.” When hiring Product Managers, remember that you’re not just hiring individual contributors, you’re hiring a key peer leader for your product team. When I think of team composition, it’s not in terms of some arbitrary cultural fit but rather of the particular talents that needed to be added to bring the team to the next level.
      For example, I think about the emotional energy the team needs. Is the team a “hair on fire” sort that panics easily and could benefit from a calming presence? Or is the team more in need of a high-energy product manager to get them excited? Is it a creative product role? An analytical one? A highly technical one? How much executive exposure will this PM have? What skills will they need to spike on to do well for themselves and the team?

    You’re going to have interviews where the candidate is amazing but not for the specific role. When that happens, be up front with the candidate. Let them know they’re not going to get the offer for the position, and tell them why. Then, shop the person around internally and keep in touch for future opportunities.

    Of the 16 people we hired, three have already been promoted from individual contributors to managers. I’ve also heard some really nice things from colleagues about our evolved team. Hearing this makes me proud. Hiring processes are a lot of work for everyone involved. We put a lot of thought and energy into our part of it, and it’s rewarding to see it come together well.

  • Fixing our Unhealthy Obsession with Work Email

    “Creative thinking requires a relaxed state, the ability to think through options at a slow pace and the openness to explore different alternatives without fear.”

    Fixing our Unhealthy Obsession with Work Email
  • All of This Has Happened Before

    A software license touches on the software, not on the human relationships which the software mediates. It is those relationships that lock us into positions where Zuckerberg’s foot is on our necks.

    The Eternal Mainframe, Rudolf Winestock
  • How not to respond to negative product feedback in the press

    In yesterday’s journal there was an interview with the CEO of The Weather Channel, talking about the future of Weather content. Weather might seem trivial, but it’s one of the most important kinds of content to get right on any platform. Companies like Yahoo, Apple, Samsung, and others agonize over how to present weather content in a way that is visually fresh but still familiar. Weather Channel just relaunched on several platforms, and I was curious to hear what they had to say.

    I was disappointed. To wit:

    WSJ: A story on the Huffington Post recently listed your weather app as one of the ‘Worst Apps Ever.’ What are you doing to fix it?

    Mr. Kenny: It’s the fifth most downloaded app on the iPhone of all apps and second on the iPad. So it has been popular there. We are working to make it work better with Android. With any app it’s important that it works well within that operating system so it can take advantage of the best features. We are also moving more of the mobile team to the West coast so they can be closer to the developers on the operating systems.

    …because God knows, nobody in California churns out crappy Apps. Right?

  • The Law of Conservation of Complexity

    When I was a wee pup working on My Yahoo, this was a crime I committed more than once. We’d argue about how a particular feature should work, narrow things down to two contradictory options, and end up implementing both as a “configurable setting.” Users would then never find or use the setting, and we’d end up looking like idiots when we had to remove it in a future release.

    In our defense, we often did this because how users “used to use the product” was very different from “how they were going to use the product.” So we’d design things so that they would work one way for “old” users who migrated into the new product, but a different way for new users who just started using it. This worked well until we wanted to update one (or both) versions of the feature, and then had to find a way to manage the dependency. More often than not, we would end up migrating “old” users to the “new” setting, removing the setting, and then moving people forward. So rather than avoid pissing off the “old” users, we just deferred annoying them to a later date. It would have been better to just place a bet on the “new” approach, and be ready to modify it if the benefit to the business (gaining new users) didn’t outweigh the cost (pissing off old users).

    The Law of Conservation of Complexity

  • Don’t be a slave to the backlog.

    I’ve been spending a lot of time helping one client with their 2011 Product Roadmap. Although we’re not “doing Agile,” I’ve introduced them to the product backlog. So far it’s been a powerful planning tool. So Scott Sehlhorst’s post on how to prioritize resonated with me.

    When creating a backlog, or managing features, you need to remember that feature priority is a tool to be used to plan your work. Don’t get too specific about the exact rank of individual items, and remember that the eventual order of implementation should reflect what from a business, technical, and user perspective. It’s a compromise. The backlog is the beginning of knowledge, not the end. 

    Don’t be a slave to the backlog.

  • Does the world need product managers anymore?

    Programmers write code, QA specialists (really just a specialized kind of programmer) make sure that it works, designers create flows, layouts, copy and graphics, and sales people sell. Sure, someone needs to keep an eye on costs and revenues, and manage the business – but that’s not what most product managers do.

    So do we really need product managers? Or do we just need someone to make sure that someone is leading the team and taking accountability for delivering something that consumers want and customers pay for? This seems to be the approach that Facebook takes.

    Does the world need product managers anymore?

  • Getting a New Team to do Cool Stuff

    When I took on my current job I was given an established product team and a mostly-new engineering team. We also had a brand new engineering manager, QA manager, and program manager working with us.

    Our job was to launch an all-new version of Toolbar while we maintained our existing versions and continued to support new corporate partners. Engineering and QA had just been moved overseas. We didn’t have any well-defined processes in place to build and maintain software. Without a clear process, or “rules of working” that described how individuals would be accountable within that process – the first few months were difficult. We struggled to prioritize current bugs against future features, and to support our existing partners while we tried to create a foundation for a new kind of partner business.

    The team leads and I spent a lot of time trying to setup, execute, and debug a product development process that worked for us. In the first few weeks I spent most of my time figuring out where our strengths and weaknesses were. Being a product guy with an engineering background I focused on finding the holes in our product and technology: features we were missing, things that didn’t quite work, where our technology worked well and where it was a smelly mess, and so on.Over a period of weeks we began to tighten up our product definition, and to understand, prioritize, and fix some of our deep rooted engineering and process problems.

    We were pretty effective, and shipped a version that was mostly well received. But I felt that the “re-launch” of the new team didn’t go as smoothly as it could have. Our team and process hadn’t been fully formed, and I didn’t have a good model to determine what to fix first. The other managers and I used our experience and intuition to decide what to look at first; we then gathered some data and made some decisions. But I, at least, never had a complete framework in mind. I’ve since done a bit of reading on the topic and mean to sum it up here.

    Forming Storming Norming and Performing: Back in 1965 Bruce Tuckman created the Forming – Storming – Norming – Performing model of group development. In a nutshell, the stages are (borrowing from the wikipedia article):

    • forming: the team meets, learns about opportunity and challenges, and begins to tackle goals as a group
    • storming: “team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept”
    • norming: “Team members adjust their behavior to each other as they develop work habits that make teamwork seem more natural and fluid.”
    • performing: “Some teams will reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision.”

    Tuckman’s model goes on to describe why each stage is necessary, and how leaders should act in order to be most effective at each stage. Much of this is common sense, but the article is still a good read, and most “team building” training in place today seems to build on Tuckman’s work.

    The Agile Maturity Model: In his post last week Tyner Blain details an Agile Maturity Model. He outlines a “hierarchy of needs” that somewhat follows Tuckman’s example. Read it for yourself, but Blain’s six levels were:

    1. Staffing the engineering team correctly – And I would replace “engineering” with “entire team” correctly. This takes the form of managing for performance as well as re-shuffling roles and responsibilities to match skills with needs.
    2. Assuring Quality is in your team’s DNA – This was huge with us. Individually, every person on the team was committed to quality, but we had no shared understanding of what level we should be shooting for. What makes a “P3” bug a “P3?” What kind of architectural limitations can we live with, and when should we refactor? We needed to come together to answer these and other quality questions, and get us to the point where we could ship a product that we were all proud of.
    3. Reducing overhead in the release process. – Oh GOD yes. You can’t have a fast, agile team, productive team that has fun unless you’ve taken most of the drudgery and variability out of the release process.
    4. Feeding the beast. – This is what I’m currently struggling with. Once you address the first three points and begin to move faster, you find yourself constantly running out of requirements for the team to work through. One way to solve this problem is to set clear, higher-level objectives and empower the engineering team to work directly with the QA, design, and product teams to build stuff. I’m a bit of a control freak, but I think that there are big gains to be made if you can empower your team in this respect.
    5. Managing stakeholder expectations – ’nuff said
    6. Continuously learning from your markets – this is a topic that deserves a post unto itself – it is the foundation of creating wonderful products.
  • Design by Objective

    I’m a big fan of managing by objective. Wherever possible, I believe that PMs, engineers, testers and designers should begin their work by first agreeing to (or at least accepting) a list of user and business objectives that a feature or product should fulfill. This will be useful in framing the many discussions that will follow.

    This week in Why Microsoft Had to Destroy Word Peter Merholz discusses how Microsoft made some tough decisions in the design of Word 2007. He specifically talks about how Microsoft and Tivo set out “design tenets” or “design mantras” which then governed the design and implementation of key features. Worth a read.