Jan 102012

Articulating the Problem is the First Step Toward Solving It

A while back, we were having some specific challenges at Return Path that were *really* hard to diagnose.  It was like peeling the proverbial onion.  Every time we thought we had the answer to what was going on, we realized all we had was another symptom, not a root cause.  We’re a pretty analytical bunch, so we kept looking for more and more data to give us answers.  And we kept coming up with, well, not all that much, besides a lot of hand-wringing.

It wasn’t until I went into a bit of a cave (e.g., took half a day’s quiet time to myself) and started writing things down for myself that I started to get some clarity around the problem and potential solutions.  I literally opened up a blank Word document and started writing, and writing, and writing.  At first, the thoughts were random.  Then they started taking on some organization.  Eventually, I moved from descriptions of the problem to patterns, to reasons, to thoughts about solutions. 

But what really put me on a track to solutions (as opposed to just understanding the problem better) was starting to *talk* through the problems and potential solutions.  It didn’t take more than a couple conversations with trusted colleagues/advisors before I realized how dumb half of my thoughts were, both about the problems and the solutions, which helped narrow down and consolidate my options considerably.

Even better than solving the problems, or at least a driver of being able to solve them, is feeling more in control of a tough situation.  That’s probably the best thing I’ve learned over the years about the value of articulating problems and solutions.  For a leader, there is no worse feeling than being out of control…and no better feeling than the opposite.  Some level of control or confidence is required to get through tough times.

I suppose this post is not all that different from any 12-step program.  First, admit you have a problem.  Then you can go on to solve it.  But the point I am trying to make is more than that – it’s not just admitting you have a problem.  It’s actually diving in deep to the potential causes of the problem, and writing them down and (better) speaking them out loud a few times, that puts you on the road to solving those problems.

Filed under: Return Path, Strategy


Apr 262011

Guest Post: Staying Innovative as Your Business Grows (Part Two)

As I mentioned in a previous post, I write a column for The Magill Report, the new venture by Ken Magill, previously of Direct magazine and even more previously DMNews. I share the column with my colleagues Jack Sinclair and George Bilbrey and we cover how to approach the business of email marketing, thoughts on the future of email and other digital technologies, and more general articles on company-building in the online industry – all from the perspective of an entrepreneur. I recently posted George’s column on Staying Innovative as Your Business Grows (Part One). Below is a re-post of George’s second part of that column from this week, which I think my OnlyOnce readers will enjoy.

Guest Post: Staying Innovative as Your Business Grows (Part Two)

By George Bilbrey
Last month, as part of the Online Entrepreneur column, I shared some of Return Path’s organizational techniques we use to stay innovative as we grow. In this article, I’ll talk about the process we’re using in our product management-and-development teams to stay innovative.

The Innovation Process at Return Path
As we grew bigger, we decided to formalize our process for bringing new products to market. In our early days we brought a lot of new products to market with less formal process but also with more limited resources. We did well innovating one product at a time without that kind of process largely because we had a group of experienced team members. As the team grew, we knew we had to be more systematic about how we innovated to get less experienced product managers and developers up to speed and having an impact quickly.

We had a few key objectives when designing the process:

We wanted to fail fast – We had a lot of new product ideas that seemed like good ones. We wanted a process that allowed us to quickly determine which ideas were actually good.

We wanted to get substantial customer feedback into the process early – We’d always involved clients in new product decisions, but generally only at the “concept” phase. So we’d ask something like “Would you like it if we could do this thing for you?” which often elicited a “Sure, sounds cool.” And then we’d go off and build it. We wanted a process that instead would let us get feedback on features, function, service levels and pricing as we were going so we could modify and adjust what we were building based on that iterative feedback.

We wanted to make sure we could sell what we could build before we spent a lot of time building it – We’d had a few “build it and they will come” projects in the past where the customers didn’t come. This is where the ongoing feedback was crucial.

The Process
We stole a lot of our process from some of the leading thinkers in the “Lean Startup” space – particularly Gary Blanks’ Four Steps to the Epiphany and Randy Komisar’s Getting to Plan B. The still-evolving process we developed has four stages:

Stage 1: Confirm Need

Key Elements

• Understand economic value and size of problem through intense client Interaction
• Briefly define the size of opportunity and rough feasibility estimate – maybe with basic mockups
• Key Question: Is the need valid? If yes, go on. If no, abandon project or re-work the value proposition.

Stage 2: Develop Concept

Key Elements

• Create a high fidelity prototype of product and have clients review both concept and pricing model
• Where applicable, use data analysis to test feasibility of product concept
• Draft a more detailed estimate of effort and attractiveness, basically a business model
• Key Question: Is the concept Valid? If yes, go on. If no, abandon project.

Stage 3: Pilot

Key Elements

• Build “minimum viable product” and sell (or free beta test with agreed to post beta price) with intense client interaction and feedback
• Develop a marketing and sales approach
• Develop a support approach
• Update the business model with incremental investment requirements
• Preparation of data for case studies
• Key Question: Is project feasible? If yes, go on. If no, abandon project or go back to an earlier stage and re-work the concept.

Stage 4: Full Development and Launch

Key Elements

• Take client feedback from Pilot and apply to General Availability product
• Create support tools required
• Create sales collateral, white papers, lead generation programs, case studies and PR plan.
• Train internal teams to sell and service.
• Update business model with incremental investment required
• Go forth and prosper

There are a several things to note about this process that we’ve found to be particularly useful:

A high fidelity prototype is the key to getting great customer feedback – You get more quality feedback when you show them something that looks like the envisioned end product than talking to them about the concept. Our prototypes are not functional (they don’t pull from the databases that sit behind them) but are very realistic HTML mockups of most products.

Selling the minimum viable product (MVP) is where the rubber meets the road – We have learned the most about salability and support requirements of new products by building an MVP product and trying to sell it.

Test “What must be true?” during the “Develop Concept” and “Pilot Phases” – When you start developing a new product, you need to know the high risk things that must be true (e.g., if you’re planning to sell through a channel, the channel must be willing and able to sell). We make a list of those things that must be true and track those in weekly team meetings.

This is a very cross functional process and should have a dedicated team – This kind of work cannot be done off the side of your desk. The team needs to be focused just on the new product.

While not without bumps, our team has found this process very successful in allowing us to stay nimble even as we become a much larger organization. As I mentioned in Part 1, our goal is really to leverage the strengths of a big company while not losing the many advantages of smaller, more flexible organizations.

Mar 142011

Guest Post: Staying Innovative as Your Business Grows (Part One)

As I mentioned in a previous post, I’ve recently started writing a column for The Magill Report, the new venture by Ken Magill, previously of Direct magazine and even more previously DMNews. I share the column with my colleagues Jack Sinclair and George Bilbrey and we cover how to approach the business of email marketing, thoughts on the future of email and other digital technologies, and more general articles on company-building in the online industry – all from the perspective of an entrepreneur. Below is a re-post of George’s column from this week, which I think my OnlyOnce readers will enjoy.

Guest Post: Staying Innovative as Your Business Grows (Part One)

By George Bilbrey

As part of The Magill Report’s Online Entrepreneur column, I’d like to share some of Return Path’s learning about how to stay innovative as you grow. In Part One, I’m going to cover some of the organizational techniques we’ve been employing to stay innovative. In Part Two, I’ll talk about some of the practices we’re using in our product management and development teams.

When we were starting our deliverability business at Return Path, staying innovative was relatively easy. With a total of four people (two employees, two consultants) involved in selling, servicing, building and maintaining product, the environment was very conducive to innovation:

• Every employee had good conversations with customers every day—We could see the shortcoming of our tools and got great, direct feedback from our clients.

• Every employee was involved in every other function in a very detailed way—This gave everyone a strong intuition as to what was feasible. We all knew if the feature or function that the client was asking for was within the realm of the possible.

• We were very, very focused on creating customers and revenue—We were a startup. If we drove revenue above costs, we got to take home a salary. Every conversation and decision we made came down to finding out what would make the service (more) saleable. It was stressful, but productively stressful and fun.

We were lucky enough to come up with good concept and the deliverability services market was born. Our business grew rapidly from those two full-time employees to where we are today with about 250 employees in eight countries supporting more than 2,000 customers.
Growing our business has been one of the most challenging and fun things I’ve ever had the chance to take part in. However, growth does have some negative impacts on innovation if you don’t manage it right:

• Supporting the “core” comes at the expense of the new—As you grow, you’ll find that more and more of your time is spent on taking care of the core business. Keeping the servers running, training new employees, recruiting and other internal activities start to take up more and more of your time as the business grows. Clients ask for features that are simple linear extensions of your current capabilities. You don’t have time to focus on the new stuff.

• Staying focused gets harder as the business get more intricate—As your business grows, it will become more complex. You’ll build custom code for certain clients. You’ll need to support your stuff in multiple languages. You find that you have to support channel partners as well as direct customers (or vice versa). All this takes away from the time you spend on “the new” as well.

• Creating “productive stress” becomes difficult—At the point our business became profitable, life became a lot better. There was less worry and we could invest in cool new innovative things. However, it’s hard to drive the same urgency that we had when we were a start-up.

Of course, a bigger profitable company has advantages, too. For one, there are the profits. They come in awfully handy in funding new initiatives. And while they can remove the “productive” stress that comes from needing revenue to keep a venture going, they can also remove the distracting stress of needing revenue to keep a venture going. Second is the ability to capitalize on a well-known brand—the result of many years of marketing, PR, and thought leadership within the industry. Third, we have access to a much broader array of clients now, which I’ll explain the importance of in a minute. Finally, back-end support and process—an accounting team that gets the invoices out, an HR team that helps make strategic hires—makes the folks engaged in product development more productive.

So what have we done to leverage these strengths while also combating the forces of inertia? We’ve done a lot of different things, but the major focus has been, well, focus. For the two to three key initiatives that we think are fundamental to growing our business, we’ve built a “company inside the company” to focus on the project at hand. A good example of this is our recent Domain Assurance product, our first product to address phishing and spoofing. Initially, we tried to run the project by assigning a few developers and part of a product manager’s time with some part-time support from a sales person. It didn’t work. We weren’t able to move forward quickly enough and some of our folks were getting fried.

Our answer was to create a dedicated team inside our business that focused entirely on the phishing/spoofing product space. The key components of the “company inside the company” were:

• Fully dedicated, cross-functional resources—Our team represented very much the kinds of folks you’d find in an early stage company: development, system administration, sales and marketing. This team worked as a team, not as individuals. Many of these resources were fully dedicated to this new initiative.
• Deadline-driven productive stress—When we launch new products, they go through four discrete stages (I’ll explain this in more detail in my next column). We set some pretty tight deadlines on the later stages.

• Customer involvement, early and often—The team involved customers in building our new product from the very beginning. From continuously reviewing early wireframes, prototypes and then beta versions of the product, we got a lot of client and prospective client feedback throughout the process.

We’re still working on the exact right formula for our “company inside a company” approach, but our experience to date has shown us that the investment is worth it.

Nov 022010

Playing Offense vs. Playing Defense

Playing Offense vs. Playing Defense

I hate playing defense in business.  It doesn’t happen all the time.  But being behind a competitor in terms of feature development, scrambling to do custom work for a large client, or doing an acquisition because you’re getting blocked out of an emerging space – whatever it is, it just feels rotten when it comes up.  It’s someone else dictating your strategy, tactics, and resource allocation; their agenda, not yours.  It’s a scramble.  And when the work is done, it’s hard to feel great about it, even if it’s required and well done.  That said, sometimes you don’t have a choice and have to play defense.

Playing offense, of course, is what it’s all about.  Your terms, your timetable, your innovation or opportunity creation, your smile knowing you’re leading the industry and making others course correct or play catch-up.

This topic of playing defense has come up a few times lately, both at Return Path and at other companies I advise, and my conclusion (other than that “sometimes you just have to bite the bullet”) is that the best thing you can do when you’re behind is to turn a situation from defense into a combination of defense and offense and change the game a little bit.  Here are a few examples:

  • You’re about to lose a big customer unless you develop a bunch of custom features ASAP –> use that work as prototype to a broader deployment of the new features across your product set.  Example:  Rumor has it that Groupware was started as a series of custom projects Lotus was doing for one of its big installations of Notes
  • Your competitor introduces new sub-features that are of the “arms race” nature (more, more, more!) –> instead of working to get to parity, add new functionality that changes the value proposition of the whole feature set.  Example:  Google Docs doesn’t need to match Microsoft Office feature for feature, as its value proposition is about the cloud
  • Your accounting software blows up.  Ugh.  What a pain to have to redo internal system like that – a total time sink.  Use the opportunity to shift from a new version of the same old school installed package you used to run, with dedicated hardware, database, and support costs to a new, sleek, lightweight on-demand package that saves you time and money in the long run

I guess the old adage is true:  The best defense IS, in fact, a good offense.

Filed under: Business, Strategy

Tags: , , ,