Micah August 11th

Feasibility vs. Possibility.

Yesterday I was on a call with a potential business partner for Lijit. With me on the call was one of our product people.

We were going down a specific path with this partner, who on the call threw us a bit of a monkey wrench. It happens. Its the internet.

Our product guy sends out an email after the call that basically indicates that the project is now dead. At the same time, I draft an email to the business partner about ways that we can potentially still work together even with the major change to the business strategy.

So who was right? The product guy for answering the question “Can it be done?” or me for answering the question “How can it be done?”

The truth is we both are correct. It needs to be determined if there is a solution to the problem, but also a need to understand the brain damage that solution might cause.

Organizations that understand this fundamental reality (product cares about the feasibility of projects, while business development cares about the potential of projects) create a positive work environment where idea flourish and projects actually complete.

Right around when I first started at Lijit, Todd Vernon wrote a post about the roles of a CTO and a VP of Engineering. Initially, I was taken aback by this section:

Another way to look at it, the CXO team should all be thinking of the next way to upset the world.  The VP’s and their Directors should be huddling on how to deliver the crazy ass stuff the CXO team is thinking of.  Of course, everyone wears a little of both hats, but in my mind that’s the focus.

After all, I had just come off of selling my company, and saw myself as someone who’s purpose in life was to “think of the next way to upset the world.” Yet, I was taking on the VP of Business Development role, which was a “by design” decision. (My focus was on learning more about how a venture backed company worked and surrounding myself with experienced rock stars like Lijit’s board and management team.)

But the question that loomed was could I do what I do best in a role that is defined by “the delivering crazy ass stuff the CXO team is thinking of”? Isnt that the role of the product team? Frankly, I was worried.

And for a year, that worry never completely subsided. Dont get me wrong, we landed big publishers, launched strong product upgrades and created great partnerships. Dont believe me? We are currently approximately 50%-ish ahead on our goals (which were scary high to start with). Clearly, we are doing something right.

Because of our successes, I never bought into the need for a dedicated product team. I didnt want a group who primary function was to tell me no. Who’s role was to determine FEASIBILITY not POSSIBILITY. To ask “Can it be done?” Not “HOW can it be done?”

Then we hired Greg Keller. Greg is a seasoned product manager and a solid blogger. He rides a bike (ok, he is a cyclist), but most importantly, understands the proper intersection of product and business development.

Over the past several weeks, the product team has expanded (and contracted a bit) to take ownership of our three products: The website (and search results), the widget and our ad network. In each case, the product path has become more clear, the important (and missing) elements have come to light, and the spots where I can make the most impact for Lijit.

What this has taught me is that if I were to build a company, I would look past the current constructs of position titles to understanding the true functions:

CEO – final decision maker; vision builder (“What do we want to be?”)

Operations – operationally focused; makes the business run (“How can we make that a reality?”)

BD – Lives outside reality, thinks about what is possible. (“What is possible?”)

Product – Lives in feasibility; thinks about how to make things reality (“What is feasible?”)

Engineering – Focused on making. They are the builders. (“Can we do it?”)

(Yes, I dont talk about sales. Sales is a very mechanical function, even though it is very necessary).

Can a small company share these responsibilities? Yes.

But, damn, its nice to have area experts.

Popularity: 3% [?]

Share and Enjoy:
  • Suggest to Techmeme via Twitter
  • RSS
  • Twitter
  • FriendFeed
  • Digg
  • StumbleUpon
  • Yahoo! Buzz
  • Reddit
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • email
  • Ping.fm
  • brian
    Micah,

    Thanks for this post.  I have been thinking about similar ideas related job functions lately as it relates to my job.  I have one of those jobs where no one seems to know what I do, including me.  Or better put no one can clearly state the role in simple clear terms.  It is helpful having a well state post like this one to help jell my thoughts.  Thanks. Brian
  • Daniel Weiss
    Grouchy product guy here. And to be fair to me, I asumed that the project was dead within the construct of what we had previously defined, and immediately went back to the drawing board to re-think it. But as much as it pains me to say it, I think Micah is right.

    Biz Dev should be pushing Product to the wall everyday with new challenges and new ways to use the product. I think it's equally important for the Product team to help focus the Business Development effort while championing the causes that make sense for the product itself, and subsequently the business. There is definitely a need for collaboration between both sides, and for each side to understand their differences and capitalize on the things they have in common (desire to drive the product and the business forward).

    I think that the feasibility vs. possibility argument could easily be expanded with "what is currenly feasible and what should be feasible, and what is possible, and should be possible. The Product manager can't be so locked into the product that they don't take into account potential improvement even when risky. At the same time, business development can't be blind to what is already in the product  and working.
  • brian roy
    I share this philosophy - but tend to phrase it in terms of managing risk or managing opportunity. Inevitably, as companies come to have a significant market share focus shifts from predominantly managing opportunity (how do we go get that) to managing risk (how do we avoid screwing up what we got). It isn't unhealthy - as long as the need for both perspectives is understood and the overarching goal is to attain the right balance for the company NOW.

    The only exception I'd take is that BD and Product Managment should be partners in disruption (or as you put it "living outside reality"). Engineering (product development) and operations have the job of focusing on what is possible and working together they make the right tradeoffs.

    Nice post.
blog comments powered by Disqus