Joseph Bou-Younes's Website

Author: Joseph Bou-Younes

  • Creating value through scarcity.

    It’s been a crazy month for me and mine as we try to plan a wedding across the continent. Now that summer is officially over it’s time to hunker down and relieve everyone’s curiosity. and catch up. So, to make for a post-free month here are two short posts sandwiched into one.

    The newspaper business is demonstrating that you can’t cut your way to growth. Newspapers and media companies spent most of the 1990’s cutting costs as a way to grow margins and revenues. As a result, most local newspapers now just reprint wire stories, attach them to local ads, and distribute them to local merchants and subscribers.

    Online, publishers are taking this “hollowing-out” a step further. Rather than selling their own ads to their audience they’re using ad networks to move “remnant” inventory, often with disastrous results.

    If you believe that tomorrow will be like yesterday – and that publishers will continue to cut down on original content as well as their sales force – then the web of the future will be a bleak landscape of AP, Reuters, or (God help us) UPI articles sandwiched between Google AdSense ads.

    But then, what about the bloggers. A couple weeks ago, Nic Brisbourne made the point that the Future of News is Scarcity. Specifically, he claimed that the way to make money as a content creator is to pick a niche, create (or source) high-quality, original content or opinion, and then generate multiple revenue streams from it. He goes on to discuss how “news” today is ubiquitous and free, but analysis and intelligence is – or can be – highly valuable.

    And finally, the FCC held several workshops on online privacy, security, and openness. My boss was invited to a few of the sessions. In typical DC fashion, the discussion centered around whether or not the government should restrict behavioral targeting, or at least allow users to opt out (like the national do-not-call registry). But Chris Kincade offered a different idea — what if BT providers were forced to describe the data that they collected, and how they planned on using it? And what if they did this in a scalable way, using a standard protocol, so that browsers could allow users to intelligently manage the data being collected about them. It’s kind of like the FCC Broadcast flag, but, you know, not stupid.

    And that brings me to my final, random point — way back in June the U.S. Supreme Court ruled that Cablevisions “virtual DVR product,” which allowed subscribers to record video in the cloud — was, in fact, legal. This is pretty mindblowing. A colleague of my described this as nothing less than the supreme court extending eminent domain into the cloud. “I pay for cable, I ‘own’ that episode of Heroes, so I should be able to record it into the cloud and retrieve it on demand.” This poses an interesting question on the legality of p2p file distribution. For example, if I subscribe to basic cable, and choose to download House instead of DVR’ing it, or watching it on Hulu, is that also now legal? What about Mad Men? Or any HBO content? And if this is legal, what is it going to do to the cable company’s own on-demand businesses? Or iTunes?

    It’s an interesting world we live in. Enjoy it.

  • Youtube gets down to business.

    It’s incredibly difficult to create a product that both delights customers and generates revenue. As a result, the usual way to build a digital media business is to first create something that users love and then, months or years later, find a way to really monetize it. Youtube followed this model for years. It now looks like Google is serious about making money from Youtube. And just in time.

    As audience and time spent continues to shift from TV to the web advertisers are looking for scalable but innovative channels through which to reach consumers. Youtube is best positioned to do this. It will be interesting to watch and see what happens.

  • Management and Practice

    The dog days of summer continue. I’d like to say that this gives me lots of time for careful reflection and reading but that hasn’t been the case. Fortunately, there’s no shortage of good material this week.

    First, the Wall Street Journal talked to Henry “Managers not MBAs” Mintzberg to find out What Managers Really Do. Mintzberg looks at how managers handle interruptions, and discusses three ways that managers can create results.

    In a similar vein, Michael Loop has an old-but-good article on how to move a software project from crisis to cruise. Read how he runs his staff meeting – I’m going to give this a try this week.

    Finally, I just finished reading “Talent is Overrated” by Geoff Colvin. Excellent book, despite being blurbed by Noel Tichy (Note to author: don’t get blurbs from narcissists. Especially those who you interviewed in the book. Looks desperate). Colvin’s description of deliberate practice reminded me of something I read last year that explained what business leaders can learn from how elite athletes train and improve.

  • Deterrence

    Today’s Wall Street Journal includes a great article on the cold war between Google and Microsoft (subscription required). The author looks at why Microsoft is launching a free, online-only version of Office, and why Google is responding in part by launching its own OS. He believes that “neither Google nor Microsoft really have an interest in challenging each other’s core franchises if it means risk to their own. Their posturing is primarily defensive—fear of loss is greater than hope of gain.”

    A good read for a Wednesday morning.

    Reblog this post [with Zemanta]

  • What the Underpants Gnomes can teach you about business on the web.

    I’ve been thinking a lot about the kinds of businesses that will start and thrive in this economy. The bulk of web 2.0 companies were built (and bought) based on the thought that they would aggregate and re-sell people’s attention. As we moved through the business cycle, some companies developed exotic ways of targeting their users (Facebook), others used AdSense to generate a trickle of revenue, others based their businesses on driving search revenue (AVG, w3i, Conduit, Dynamic Toolbar, Freecause) and still others just left the problem for their future owners to solve.

    As the economy slowed, AdSense yields plummeted and publishers became frustrated with the quality of the ads. Advertisers became more conservative, cut their “experimental” budgets, and avoided new targeting techniques. Folks like AVG became more aggressive and successful, and have spent the last few years creating new toolbars, virus scanners, and other tools to drive search distribution. But outside of search distribution, the “attention” businesses have been getting creamed.

    On the supply side, you’ve got dozens of new channels (mobile ad platforms, dozens of new ad networks, Facebook, and so on) generating record levels of ad inventory. On the demand side, all of the major brand advertisers have pulled back, and two of the biggest categories – autos and financials – have slashed or eliminated budgets. I shudder to think of what will happen if the U.S. pharmaceutical industry is finally subjected to price controls.

    Dharmesh Shah wrote a great post a couple months back about the challenges of building a business for the attention economy. The crux of the problem is that people only have a finite amount of time – and attention. On the other hand, people can always – at least in theory – make more money. Shah goes on to list out three major difficulties with building a business for the attention economy:

    “1. Attention Is A Scarce Resource: Attention is a bit limited and fragmented. I’d argue that it’s getting increasingly harder to get people’s attention…

    2. Battle of User and Advertiser: There’s a conflict between getting monetizable attention and solving the user’s problem…

    3. Advertisers Make Lousy Customers: Even with all the fancy content-matching algorithms that pair up a given ad to a given context, I still don’t like advertising. I really don’t. I can see why it’s important in a lot of industries — but I don’t know that software is one of them. Given the choice between solving a user’s problem (which I understand, and hopefully care about) and an advertiser’s problem — I’d choose solving the user’s problem…”

    Selling attention is hard – but everyone accepts that it’s hard. So they just include it in their business plan as the second step of the “Underpants Gnome Business Model.” For those who haven’t heard, the model is:

    Step 1: Steal Underpants
    Step 2: ???
    Step 3: Profit
    http://media.mtvnservices.com/mgid:cms:item:southparkstudios.com:151037

    Unless you have some very deep pockets, and have a multi-year technology or science problem to solve, this just shouldn’t fly. That’s one of the reasons I’m spending more time looking at wallet-based (as opposed to attention-based) business models over the next few months. Amazon and ebay are big, but they’re not everywhere – yet.

    Reblog this post [with Zemanta]

  • 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.

  • Evolve.

    This month’s Fast Company features a cover story about Amazon’s Kindle. It describes how Amazon could use the Kindle to squeeze publishers out of the book value chain. It also talks about how Apple might respond, and what the ensuing battle might look like.

    Over the past few years I’ve been impressed by Amazon’s willingness to create products and services in markets where there still is really no business – like Kindle. They constantly look for opportunities to leverage their distribution, retail expertise, and infrastructure to grow their business and increase their relevance to consumers and merchants. On the other hand, ebay stuck to its knitting, failed to grow out of the U.S. auctions business, and had its lunch eaten by craigslist.

  • 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.

  • Rule 2: Don’t be a victim.

    As a product manager it is tempting to blame failures on the action – or inaction – of others. This is dangerous because it allows one to avoid responsibility for the commtiments they make.

    To be a great product manager you have to be a good leader. That means holding yourself accountable. The best definition of accountability I’ve seen describes accountability as “a personal choice to rise above one’s circumstances and demonstrate the ownership necessary for achieving desired results (Connors, Smith and Hickman, ‘The Oz Principle‘).”

    When I worked on the Yahoo! home page a colleague approached me with an idea that would generate significant new revenue. So the two of us sat down to check his math and figure out how to implement it.

    It turned out that he was right, but that to implement his idea we’d need to rely on a dysfunctional team in a distant office. As a result, completing the project would require both of us to spend a lot of time doing other peoples’ jobs.

    So we started the project and began to muddle through. Soon enough, the predicted problems arose and began to slow our progress. Frustrated, I took the issue to my boss and asked for his advice. I described the problem to him and he gave me some detailed guidance. Then, we wrapped up the conversation something like this:

    “Will this make money for Yahoo!?”

    “Yes.”

    “Is it good for the user?”

    “Yes.”

    “Do you still want to do this?”

    “Yes, but it will be a huge pain in the ass to implement.”

    “Then don’t be a victim. If you really want to do this, you can – and I’ll give you all the help you need. It’s up to you.”

    And so I had my revelation.

    This project would require me to get my hands very dirty – but the business benefit was huge, and if the project succeeded I would get a lot of the credit. So I decided to commit and push it through.

    It turns out that the problems weren’t nearly as big as I originally thought. After a week or two of messy work – which consisted mostly of managing people who didn’t work for me – we got things on track and launched the feature. And it actually performed as expected, and drove a significant amount of new revenue into our business.

    Too many people fall victims to their dependencies. Victims blame others for their failures rather than taking accountablity for things that happen and trying to correct for them. Leaders take accountability for what they commit to do.

    That said, smart leaders are very careful what they commit to. You can only take on a few of these “special missions” at once and so you need to save them for the most important things. You also have to accept the fact that sometimes, the most important things will be things that you are ordered to do, not necessarily the things that you feel the need to do. When this happens, argue vigorously, accept the orders of your superiors, and plan for the “I told you so” contingency. That way, if it turns out that you were right all along, you’re still in a position to fix the underlying problem.

  • Rule 1: “No, you are not the user.”

    For all my time at Yahoo I’ve had the good fortune of working under Tapan Bhat. I worked for him directly for the first year as we tried to sort out My Yahoo!.

    “My” was and is a pretty geeky product, with a lot of power user features. Our job was to figure out how to turn it into a mass market product. Having it for several years before abandoning it I felt that I had a great sense of what users wanted in a “personalized home page,” and what we needed to do to make the product grow again. I spent endless hours working with our engineering team to spec out what I thought were killer features, only to see them blow up in the lab. (Fortunately, Tapan and the designers kept most of the really dumb ideas from ever leaving paper). It turns out that I had a great idea of what I wanted on a personal home page, but no clue as to what our users actually needed.

    At the time our strategy was to upsell front page (yahoo.com) users to My Yahoo! I realized that I was nothing like a typical front page user, and so everything I came up with fell flat. To make matters worse, I had a hard time identifying and empathizing with those users, and reading the research didn’t help.

    What finally worked was to use people I knew, who used the home page, as personas. I had classmates, parents, and siblings who all used the front page, and like to personalize things. So what worked for me was to put myself in their shoes and reconceive each potential feature in terms of how – or if – they might understand it.

    Eventually, putting myself in their shoes became second nature. But from time to time I still get worked up about a product I own not working exactly as I might want it to, or a feature I really need getting deprioritized by someone on my team. If they’re wrong, they’re wrong. But often times I just take a deep breath and then slowly say “No, Joseph, you are not the user.”

    Update…

    Marty has his own, similar rule in his “Top 12 Product Management Mistakes.”