Archive for the 'Small business' Category

A learning moment about Plan B

Published August 31, 2010 Small business , leadership , startup Leave a Comment
Tags: ,

No, I’m not talking about that Plan B. I’m talking about backup plans (like the time I called a motel near my campsite to inquire about vacancies, just in case we needed to vacate our site due to heavy rain.)

As a compulsive planner, I really can’t help myself.  For every truly important Plan A (camping included), I generally have at least a Plan B, if not C through F.  I play to win.  I generally try to come up with many different ways to achieve an end to maximize the odds of success. This approach has worked marvelously well for me throughout my life for the things I truly cared about.  So I’ve felt smug about my great hit rate, until recently when I was challenged on my approach.

Someone who was a big champion for a Plan A noticed that I was making a Plan B, and he got noticeably upset.  He told me that my approach indicates that I was not aggressive enough in my pursuit of Plan A, that I don’t believe in it enough, and that I should channel my energy back to making the primary approach work.

So I sat back and thought about this.   Did I put any less energy in Plan A’s just because I have Plan B’s?  Definitely not.   I still chased  after the holy grail in full steam.   I simply believe in covering all of my bases since Plan A was full of risk.  Apparently this can be seen as a form of betrayal by people who are highly invested in Plan A.

As I am pretty left-brained, I find this sentiment illogical and hard to empathize with.  It appeared to me that this person was  responding emotionally, not rationally, to the situation, since I have the facts on my side.  Yet I accept that this person’s sentiment is no less valid than mine.  People Are Different And That’s OK (that was the first and most important takeaway from all my years in ethnography research.)

This was a learning moment.   I learned that I have to work harder in managing expectations in situations like this.  I am not going to stop making Plan B’s.  I just need to make it quite clear that this doesn’t mean I support Plan A any less.

I had a chat with the person, and all’s well that ended well.   I hope I’ll do a better job at managing perceptions next time.

Measure employees by output, not hours worked

Published August 26, 2010 Small business , leadership , startup Leave a Comment
Tags: , ,

Today I read a great post from Ben Yoskowitz’s Instigator Blog, titled “How many hours should a startup employee work?“

I find myself having a flashback of a conversation on the same topic that I had with a friend in a startup.  There were a ton of milestones to be met in the next 6-9 months.  This friend was concerned about the schedule.  He thought that the way to get all this stuff done was to have everybody work 60h+ per week until all the milestones were met.

Setting the topic of burnout aside, my friend had fallen into the same trap mentioned in Ben’s post: equating hours worked with value created.   This is probably the biggest misconception for anybody leading a team.

Hours and output are at best correlated, and at worst a substitution for an analytical, thoughtful approach to team management.  An hour worked by person A is not the same as an hour worked by person B, even if they have the same job description and are working on substantially similar projects.  One should always measure an employee by their output and productivity, never blindly by the hours they put in.

I personally know a few wonderful people who I like and respect greatly on a personal level,  who work the longest hours of anybody else in their organization, but still manage to miss the most basic expectations for their work output.   A lot of times, these people were simply put in the wrong jobs.

  • The person has chosen a profession that they have low aptitude for (e.g. someone with a passion for creative writing went to engineering school and became an electrical engineer instead).  They never really “got” their chosen profession and could not meet the expectations of themselves or their supervisors in the basic functions of their job.
  • The person joined a company in a growth state, then the company did a restart.  The type of work and the way it needed to be done changed dramatically and the person is not able to adapt their work style to meet the company’s changing needs.
  • The person is a generalist who was put in a new role out of expediency (which is not unusual in a startup situation). While he or she is a hard worker, he or she doesn’t have the requisite training to pick up the skills necessary for the new role.

I also know a lot of people who I respect much less, who stay at work all day and all night to create the illusion of working hard. In reality, they spend most of this time goofing off while physically present.  I had to put one such employee on a performance improvement plan to shape up or be let go for cause.  (He did shape up with my structured improvement plan – he was at work for fewer hours and got more done thereafter.)

With these types of fundamental issues, working longer hours achieves nothing but to burn people out, strain their relationships with their loved ones, and breed resentment (if they see their coworkers putting in fewer hours than they did).  Much better to manage a team by setting expectations of work output, negotiating the deliverable dates such that they are aggressive but not completely unrealistic, and pacing the team so they work reasonable hours most of the time. Only then will they have the reserve to go the extra mile and put in an occasional couple of long weeks for a true emergency.

On Competitive Advantages

Published August 25, 2010 Small business , leadership , startup Leave a Comment
Tags: , ,

I just stumbled across a fantastic series on bad startup pitches from Jason Cohen’s blog.  It’s titled “5 lessons from 150 startup pitches“.  I find myself agreeing violently with 3 of the 4 posts that relate to competitive advantage.

I had a recent conversation with a friend who is working on a pitch for a new venture.   The product concept is a good idea, but the way it is currently presented, it veers dangerously close to the offerings from a couple of competitors.  When I asked what the competitive advantage was, the answer was quite diffuse:  “we have Feature X, that’s our differentiator.”  “Our UI is so much better than theirs it will blow them out of the water.”

It gets worse: “Company X is charging $Y for a substantially similar service. We are going to come out of the starting gate charging 50% what they charge.”  At some point I will write a post on what not to do in pricing strategy – but that’s a conversation for another day.

So what qualifies as valid competitive advantages?  Here are some candidates.

  • First mover advantage – you are the first to solve this particular problem in this particular way. (This could work for and against a business though. It’s much easier to launch a product into an existing category than to make your own product category.)
  • Deep knowledge about your target market’s needs and wants, enabling you to build something that solves their problems better than the competition has solved their problems.
  • Special soup technology nobody can easily copy, even if they hire away your chief engineer or read and understand all of your published patent applications.
  • Deep relationships with big fish at key potential customers (if B2B) that gives you a big head start on business development.
  • A team with domain expertise that can execute at twice the speed of their competitor’s team.

What are some competitive advantages you have enjoyed in your experience?

Startup learnings

Published August 6, 2010 Small business , leadership , startup Leave a Comment
Tags: ,

I have been invited to give a talk to some MBA students about life in the startup landscape. I reflected on my experience and boiled it down to these bullets.   Do they match your experience?  I’d love to hear what you think.

  • Be audacious. Aim very high and fail sometimes.
  • Be open. Listen to your customers’ needs and wants.
  • Be humble. Listen to your advisers who have experience that you don’t have.
  • Be nimble. If something doesn’t work, fix it now and move on.
  • Be focused. Keep the Main Thing the Main Thing.
  • Be fact-based in decision making, but learn to trust your gut too.
  • Hire some generalists and some specialists.
  • Pace yourself while working hard. It’s a marathon, not a sprint.
  • Don’t take yourself too seriously. Have some fun along the way.

Stage-Gate and software don’t mix

Published June 25, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , , ,

I recently read this interesting article from Nielsen Wire on new product development for consumer packaged goods (CPG).  This article talks about how to realize the most revenue from new product development in the CPG space. Key takeaways:

  • Manage ideas loosely (have an innovation team live far, far away from headquarters with low involvement from senior staff)
  • Manage the process precisely (a formal Stage-Gate process is recommended)

I found myself scratching my head over how to translate these astounding insights to high tech new product development in a software startup or small business environment.  My take: they don’t translate.

I agree in principle with managing ideas loosely – no blue sky work can occur if every new idea is shot down by someone who is too concerned with the here and now.  But is it prudent to have a completely separate blue sky process in a startup when the entire startup needs to all march to the same tune?  This structure seems advisable only for corporations with a strong established business, which generates the revenue to fund the innovation process.  For pre-revenue or early revenue-bearing businesses, there is no separation between new product development and the business itself – they are one and the same.  A company like that hasn’t earned the right to send a team off to another city and go blue-sky on everybody else.

The second point made in the article, regarding tight management of process, is even less transferable.    Let’s take the application of Stage-Gate for an example.  Imagine managing web software development with a 2 week release cycle, where each release must go through the 5 typical gates:

  • Gate 1: initial screen (to decide whether the idea is worth pursuing)
  • Gate 2: approval to proceed to building a business case
  • Gate 3: approval to proceed to development
  • Gate 4: review outcome of development before going into QA
  • Gate 5: review outcome of QA, decide whether to release

“Absurd” is the only word that comes to mind.

I believe in only as much process as it takes to maximize efficiency and guarantee a high quality of output. (That is a whole lot more process than most entrepreneurs I work with are used to.  I can’t help it – if I am to execute I have to set up an efficient environment.)  I also believe in tailoring processes to suit the industry and nature of programs.  Different processes are established for different things.  You can’t apply a consumer electronics hardware development process naively to shrinkwrap software development, and you cannot apply shrinkwrap software development processes naively to web application development.

Stage-Gate can work for CPG and hardware development programs with a long turnaround time, but is completely inappropriate for fast turnaround programs and most software programs.   It behooves senior management to understand enough of the principles of Stage-Gate versus Agile or Mini-Waterfall so they can apply an appropriate level of oversight without bogging everybody down with inapplicable processes.

On deadlines

Published June 8, 2010 Small business , leadership , startup Leave a Comment
Tags:

I just read an awesome post on deadlines from Seth Godin. The key takeaway is that deadlines work and we should set deadlines and stick to them for ourselves. Amen to that!

His post illustrates something unflattering about human nature.  Many people procrastinate until, or after, the very last minute. And then they spend far more time making excuses, complaining about extenuating circumstances that made them miss a deadline (and presumably miss some sort of benefit) than it would have taken them to hit that deadline to begin with.

A culture that tolerates misses removes accountability and encourages sloppiness in execution.  Conversely, a culture that doesn’t tolerate excuses and celebrates milestones as they are achieved on time sets the stage for an empowered team to execute effectively and with a great quality of output.

Rallying a team behind unsexy projects

Published June 3, 2010 Engineering , Product Development , Product Management , Small business , Software , leadership , startup Leave a Comment
Tags: , ,

It’s easy to get a team psyched and energized on sexy projects – the kind that have huge and visible customer impact, which gets your senior management and your board all excited.  Think of a software UI and workflow redesign that makes it ridiculously easy for your target end users to achieve their goals within your product, or a release of a new product with new and highly visible features.

It’s not as easy to get a team psyched and energized on highly strategic projects which, when done perfectly, has no visible manifestation whatsoever (except in subtle ways, such as improved performance of a software application, or a reduced incidence of rare catastrophic failures).  Think of architecture work, refactoring, server architecture rework for hosted applications, cost reduction exercises for existing products and so forth.  These sorts of projects are like plumbing: nobody notices the work if it is done right.

There are many ways to rally a team.  A steady stream of ongoing feedback and encouragement is a must.  Small victories should be celebrated as they come up.  I make sure my team is well fed if they have to work weird hours in support of some big initiative.  I like a little champagne to celebrate major milestones.  A private word of thanks and some token of appreciation is always appropriate as well.  But a much bigger part of it is public recognition of a job well done.

For jazzy projects, this is easy: everybody can see the end results and the quality and speed of execution of the work is self-evident.  For plumbing projects,  it’s much harder: even senior management often misses the magnitude of the achievement.  One could have a team toil for months on a huge project with everyone else scratching their heads on what this team achieved with all those man-hours.

In these cases, it is imperative that we explicitly call attention to the speed of execution and the quantity and quality of the work done by the team in a public manner, and make sure the team is recognized for excellence in execution.  We simply have to work harder to frame the achievement in a way that is immediately understandable by people outside the fray, so they can appreciate and applaud the contribution that the team made to the cause.

Issued patents don’t represent innovation

Published June 2, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , ,

Are patents symbols of innovation in this day and age?

My take: NO.

Today I went to the USPTO site on a whim to see whether I had any new issued patents (my last company had a huge patent portfolio with me as a co-inventor in over half of them.)   Lo and behold, 3 of them were newly issued.

This is gratifying since I got to update my issued patent list.  But it got me thinking about the whole system.

First of all, I should add that I do believe there is value in the patent system as a mechanism for startups and small companies to protect their core intellectual property, build an image as an innovator in their chosen domain, and shore up their valuation during fund raising activities.  Having mostly worked for startups with a hardware component, I have seen first hand how one can really monetize a strong patent portfolio and defend one’s position as a thought leader in the marketplace.

I agree with Brad Feld in general about the absurdity of software patents, but I believe

(a) novel hardware and human interface ideas are generally worth protecting,

(b) novel algorithms that deal with very complicated math/physics problems are generally worth protecting too (even if they are implemented in software).

That said, I have become increasingly disillusioned by the entire US Patent process as a way to protect and encourage innovation and invention.  Here are some anecdotes from my prior lives.

  • The US Patent Office allowed a patent application for which the WIPO (World Intellectual Property Organization)  found a piece of prior art it apparently read on.  We had to modify the claims for the WIPO filing and file an IDS (Information Disclosure Statement) with the US Patent Office about this new piece of prior art, which promptly issued the patent as is with no changes required in the claim set.
  • The US Patent Office once issued us a final rejection letter – with instructions on how to rewrite the claims and pay a fee so we can get it allowed in the next round.   (How’s that “final”?)
  • The US Patent Office let a few claims through which I believed was too broad to be defensible, and too nonspecific to protect the associated core technologies.  And I think some of them read on prior art.  This is, of course, our fault; we did a lousy job  on claims development.  Still, the fact that those claims came through said something about the due diligence that the patent examiner did NOT do.

It’s a fine theory that the patent process rewards novel inventions, but the reality is that the system is not equipped to tell the difference between a truly innovative idea and a truly pedestrian idea. Consequently, anyone with an adequate budget, a moderately articulate patent application, several years of patience, and substantial flexibility about the language of the claims can get their US patent application to eventually issue.  The only patents I’ve seen that aren’t issued are those that were abandoned due to lack of budget.

At this point, my personal opinion is that a strong patent portfolio is a business tool, and is fundamentally not correlated with whether a company owns any intellectual property of note, or has invented anything novel that is hard for competitors to imitate.   We pay to play in the high tech world and I suppose I have to be at peace with that.

Product strategy: finding patterns in chaos

Published June 1, 2010 Product Development , Product Management , Small business , startup Leave a Comment
Tags:

I had an informational interview with a young friend who was interested in starting a career in product strategy.   The first question that came up was this: what IS product strategy?

In thinking back through my various encounters with strategy work, I came up with the following core elements:

  • Data collection.  Any strategy work without data is just guess work. Data is crucial for helping us make fact based decisions.  For instance, one could be in the field doing contextual interviews to collect raw data for a persona project. That’s data collection.
  • Data analysis. Once you have the data you must crunch it to see what it means.  One tries to find patterns in the chaos of raw data.  For a persona project, that means looking for common threads amongst the one on one conversations.
  • Recommendations. This is what I call the “so what” part: given this information, what should we do moving forward?  For a persona project, this involves naming the primary and secondary personas and explaining why they make sense.

To some extent, the first two elements are skills that can be taught relatively easily to anyone who has a reasonably good aptitude and is capable of seeing data through objective lenses.

Coming up with recommendations, on the other hand, is a whole different proposition. It involves integrative thinking; it requires those doing this work to synthesize new data with domain knowledge and other information.   It involves finding patterns in the chaos of raw and synthesized data.    It’s not unteachable; but it does involve experience with the subject matter.  A few years on the job doesn’t hurt either.

I enjoy all three elements, but ultimately, it’s the recommendations that matter.  It takes a lot of hard work to get to the point where you are ready to make a recommendation.  But once you do, and if you are right, nothing beats the exhilaration of having helped to point the company towards a direction that will mean success for everybody involved.

When not to roadmap (hint: Lean Startup)

Published May 28, 2010 Product Development , Product Management , Small business , startup Leave a Comment
Tags: , , ,

Recently I had an interesting debate with an old friend about product roadmaps.

Before I share that story, I should disclose that I am a strategy junkie and a compulsive planner.  I make lists in my sleep.  I have driven the product strategy and maintained the product roadmap for the last several companies I was associated with.  A roadmap exercise is the best way for the product team to get out of the weeds and see the forest, and everyone I worked with knew where I stood on that topic.

So I found it funny that I ended up waxing lyrical about a completely opposite position in this debate. My friend was arguing for the need for a roadmap in a startup in its infancy (6 months after incorporation), to lesson thrashing and reduce waste.  I instead argued that for such a young startup, a roadmap is worthless.   Instead, the company should direct its energy towards testing their ideas with customers until the company hits the killer idea.

In such a young company, thrashing is not waste.  Overinvesting is.  On this point I am 100% in alignment with the Lean Startup philosophy.

In Peter Bregman’s words, sometimes not having a plan can be the best plan of all.  Only when the killer idea is well defined, the target market has been identified and quantified, the personas have been decided on, and a product platform has been developed, does it makes sense to work on product strategy and create product roadmaps.  That’s typically at least 1-2 years after incorporation.

I often come across as a roadmap nazi because I harp incessantly about its importance as a symbol of a well thought out product strategy.   But like all debates, absolute statements are silly.   If your company is young, iterate until you are in a position to grow. If you are in a growth state business, then by all means, roadmap and plan to your heart’s content!

Next Page »

Subscribe in a reader

Subscribe by Email

About Elaine Chen

I'm a 17-year veteran engineering and product management executive in the local Boston startup landscape. Click here to view my full profile.

Twitter Updates