Archive for the 'Small business' Category

Note: This multi-part post is for first time founders. Anyone who has done it before will already know all this.

If you are a first time founder, what should you obsess about? Hopefully, you are all over the market opportunity. You are doing customer development to understand buyer and user personas, building knowledge about the problems they face, and evolving hypotheses for how to solve these problems. You are working on building a great product. You are focusing on the build-measure-learn loop and iterating and pivoting fast to incorporate market learnings. You are working on putting together an A team to get the job done. And you are managing your time so you are able to focus on these value generating activities.

Instead, I find that a lot of first time founders spend a disproportionate amount of time sweating the details on administrivia. Hiring professional service providers. Company formation. Making sense of Cap Tables. Setting up a bank account and doing the accounting. Keeping track of business contacts. Company positioning and messaging. Company naming. Corporate identity. Web site. Social media. Filing patents. You get the picture.

This stuff is not rocket science. It has to be done, but it doesn’t add value. Figuring out the core premise of your startup – that needs to be the main thing. Everything else is a distraction.

To help young founders spend the least possible time on this stuff, I am putting together a few posts that helps summarize some of the key tasks as well as pointing out some possible resources to execute those tasks. Hopefully this will also arm you with the vocabulary to learn more.

Hiring professional service providers

What is this? Professional service providers can help you with the mechanics of starting and running a company.

Why do it? A small cash outlay can save you a lot of time and the trouble of learning things outside your area of expertise (such as how to file corporate taxes) that adds no value to your startup or your professional trajectory.

Who do I need? A corporate attorney, a contract accountant, a creative web / graphics service provider, an IP attorney.

Company formation, a.k.a. “incorporation”

What is this? The process by which the startup becomes a separate entity from the people who own or operate the business.

Why do it? To protect your personal assets in case your company gets sued / owes money, or some such.

What kinds of entities are relevant? Choice of C-Corp, S-Corp, or LLC. This is a critical choice as it has significant tax implications. Forbes has a great article on C-Corp versus S-Corp, and the Small Business Administration has an article on LLC that you should read. Work with a corporate attorney who can help you pick what works for you.

How do I file for incorporation? You can file your own incorporation papers with the SEC of your state. The easiest thing to do is to hire a corporate attorney to do it for you.

What is this? A cap (capitalization) table lists who owns what stock in the company.

Why do it? To define ownership of the company. You need it immediately if you are incorporating with more than 1 founder, and you definitely need it when you raise your first round, or when you need to define an option pool for new employees.

Where can I find examples of cap tables to learn more? S3 ventures provides a fantastic excel template for free – you can download it here. Google any words that you don’t know in there and relax, you don’t need to understand all of that all at once. Venturehacks has a blog post with a video link depicting the process, as well as an excel template you can buy for $9.

Who can help me with this? Your corporate attorney.

Setting up a business bank account and business credit card

What is this? Opening a bank account and obtaining a business credit card for your startup, that is separate from your personal bank account and credit card.

Why do it? Keeps things clean and separate and saves you many hours of busywork writing expense reports from yourself to yourself. Keeps the credit histories separate.

Who can help me with this? You don’t need help on this one – just pick a local bank with a no-minimum-balance checking account product. Amazon business card is a great product for the corporate credit card.

Doing the accounting, and the software to do it with

What is this? Keep track of money in and money out for your business, separate from your personal finances.

Why do it? Some day you will get audited and you will be glad your books are squeaky clean from the start.

What do I need to do? Hire a contract accountant who can set you up with Quickbooks. You can do the Quickbooks management yourself until it gets unwieldy, then you can contract it out or hire a staff accountant. I have seen people use Quickbooks through Series B – I would suggest going with a professional ERP (enterprise resource planning system) before you get that far, especially if you are selling product and need to manage inventory.

Who can help me with this? A contract accountant.

Keeping track of business contacts via a CRM (Customer Resource Management) system

What is this? A CRM system helps you keep every detail of every conversation with every prospective customer / vendor / contact in one place via a database.

Why do it? Conversations can be long range and have a long half life – important to keep track of people, companies and tracks so nothing falls the cracks. Spreadsheets or documents or email trails are not scalable beyond a few conversations.

Who can help me get this done? You will have to set it up yourself. Then everyone who interacts with outside contacts should get in the habit of logging their notes and conversations in the system. There are free tools like the Zoho CRM, with limited functionality, or you can always spring for salesforce.com when you are big enough.

That’s enough for starters. I’ll cover basic marketing presence in the next post.

A few months ago, I was interviewed by a group of entrepreneurs from Mexico about my thoughts on innovation. Here are some key discussion points that came up in our conversation.

What is innovation?

When people use the word “innovation”, most of the time they are thinking about scientific or technological innovation. To me, however, innovation simply means coming up with new ideas on how to solve problems, and then successfully implementing these ideas into viable solutions, and it applies to every discipline.

Coming up with a non-invasive way to test a diabetic patient’s blood glucose level is innovation. Coming up with novel ways to incentivize a sales channel to double their product sell through rate is innovation. Coming up with visualization tools for budget-versus-actual analyses to help a cost center manage its expenses is innovation.

Why is innovation key in a startup?

Innovation is critical for any organization that needs to maintain a competitive edge, but for a startup, it is a matter of survival. Startups are always pressed for time and resources. They are constantly looking for new and non-obvious ways to solve problems and meet objectives quickly. They are constantly solving new problems never solved before. Being creative and flexible is key.

How do we come up with a process for innovation?

In my mind, the very nature of innovation is non-linear, whereas processes and frameworks tend to be rigid and structured. In my opinion, innovation and set processes don’t go well together. Rather than creating a documented process, we should focus on creating an environment that encourages risk taking and spontaneous, out-of-the-box thinking, which in turn encourages and nurtures innovation. We should make it ok for team members to try things that aren’t guaranteed to work. Also consider building in some intentional slack, so people have the space and breathing room to come up with great ideas during their down time.

How can you tell if your organization is innovating successfully?

It’s one of those “you know it when you see it” things. An innovative organization simply exudes creative problem solving vibes. There are also objective signs: more patents being applied for; faster turnaround in responding to market needs and customer requests; loyal and happy customers who trust an organization to solve their problems effectively; these all help to show that the organization is innovating where it matters.

Are there best practices for encouraging innovation in a startup?

One thing I advocate is the “tiger team approach”. I like to pull a cross functional team together from different departments. This project team gets together and works on a well defined problem with great focus until it is resolved. The diversity within the team ensures that the problem is looked at from multiple perspectives. Effective collaboration results in effective innovation.

There are a million books out there teaching various aspects of entrepreneurship, many of them I consider required reading for any aspiring entrepreneurs in today’s startup ecosystem. But I agree with Bill when he says that all these books and materials teach only a part of the whole. First timers need a comprehensive introduction to the whole tamale. Which Bill does fantastically in a nice dose of MIT style firehose.

Bill hammers home the importance of testing your assumptions in the field. Other books do this too, but Bill makes it practical. The single most fatal mistake an entrepreneur can make is to get so attached to their starting idea that they push forward despite warning signs along the way. A rigorous approach to testing assumptions is a powerful weapon against getting caught up in the focus group of one.

What I particularly like about this book is the approachable way Bill demystified the sales process, explained sales models, and outlined how to quantify and track key metrics like LTV (Life Time Value for a customer) and COCA (Cost of Customer Acquisition) beyond the blunt instrument of a financial statement. The chapters on sales and marketing are particularly valuable to technical founders who haven’t personally seen marketing and sales in action.

Another wonderful thing about the book? It doesn’t discuss product roadmap until Step 24 of 24 – which is exactly apropos. First, you establish your right to exist. Then, you can worry about product roadmap. A product no one buys is not a business. Fixating on future products before the value proposition has been proved on the first offeringis a fool’s errand.

Here are some quotable (tweetable?) quotes that I particularly like:

“The single necessary and sufficient condition for a business is a paying customer.” (On why having a product no one buys doesn’t make it a business.)

“Focus is the most important skill for an entrepreneur.” (On not boiling the ocean)

“If there is already a market research report that contains all the information you need, it is probably too late for your venture.” (On why one must do primary research instead of relying on Google search to learn about the market and customers)

“Get started doing, rather than getting stuck in analysis paralysis.” (On not agonizing over whether you have picked the right beachhead. You have incomplete data – just make a call and get going.)

“(Entrepreneurs) overestimate the enthusiasm their customers has on their product.” (Touché.)

“If the only feedback you get is ‘everything is okay’, then it is likely the customer doesn’t care much about your product and its value to them.” (On anticipating and embracing negative feedback)

“You cannot will a market to exist any more than you can change the laws of thermodynamics.” (On the need to be willig to change fundamental assumptions, including the choice of a target market, based on new data)

“Free is not a business model.” (Enough said.)

“Costs shouldn’t be a factor in deciding price.” (On how cost based pricing almost always leaves money on the table.)

“It is always easier to drop the price than to raise the price.” (Duh!)

“A sound ratio for the LTV to COCA is 3:1.” (Via David Skok – a good guideline for unit dynamics once a startup has reached product market fit.)

“The COCA will almost always start at a very high point because you need to first create the market.” (Something a lot of first timers don’t realize, causing panic, when it is part of the process to develop the business model.)

I very much enjoyed reading this book and the many examples. If you are a first time entrepreneur who wants to learn what questions to ask, definitely add this book to your collection. It is a dense read, but it will arm you with the vocabulary and concepts to probe deeper in each area. Highly recommended.

Years ago when I inherited my first truly complex, multi-disciplinary program, a beast with 1.5 million lines of code among other things, a wise mentor told me about managing to three things: content, schedule, budget. Namely, one gets to pick two out of three, and the third item has to float.

I didn’t realize it at the time but most other people refer to this triad of parameters as “good, fast, cheap – pick two”.

This is great as long as we are doing armchair product development. However, in real life, for better or for worse, these three parameters almost always look overconstrained.

GOOD: For any new product or service, intensive customer development will tell us the absolute minimum set of features/functionality we need to provide. Once you truly grok the buyers and users and have invested in coming up with the short list of stuff they need, it is really, really hard to cut anything off of this list.

FAST: To keep pace with today’s fast moving markets and customer needs, everything that needs to be done needs to have been done yesterday, or we risk becoming irrelevant. One can never release products or services quickly enough to meet the needs and expectations of the business and its stakeholders.

CHEAP: There are very few startups (or any other businesses for that matter) where the product organization isn’t short staffed and/or watching the run rate like a hawk. Even if budget is unlimited, there is the mythical man month issue to contend with. The current headcount almost always defines the budget for any internal projects to be done within the next few weeks.

How do we run projects when all three parameters appear fixed? Asking people to do more faster on a going basis isn’t awe-inspiring or effective (at least not if you care about burnout prevention).

What I find is that while all three look equal, if we take a few moments and think about the situation critically and rationally, we can usually find the one that is less equal than the others. The one that is a nice-to-have disguised as a must-have. With the grace of some corporate will, there is often maneuvering room on this one.

In some cases, it might be that the headcount is fixed (a true budget constraint), and a specific delivery date that are set by external circumstances outside of our control (a true schedule constraint). For instance, if you are in consumer electronics and you want your product to be in physical Best Buy stores for the holiday season, you are going to be showing the buyers a looks-like, works-like product in final-looking packaging in April, together with every other CE product that is competing for shelf space during the same holiday season. In that case one might have to make some hard choices and cut beyond the MVP feature set in order to meet that date, with a plan to augment the product with additional features and functionality later on (e.g. with software updates delivered over time).

In other cases, it might be that your headcount is fixed (a true budget constraint), and you need to get enough work done to facilitate a specific workflow for a specific customer or set of customers: your product or service is useless until you achieve critical mass on this workflow (a true content constraint). In that event, whatever the business pressures might look like, you simply will have to negotiate enough elapsed time to get the job done.

At the end of the day, overconstrained projects are self-inflicted problems for an organization. If we are willing to ask the hard questions, and make difficult tradeoffs with eyes wide open, we can usually find a sensible solution that optimizes the outcome for what truly matters.

Like any other manager of a functional group, the product development manager wears many hats. He or she is a technical lead, a head coach, a Gantt meister, an HR specialist, a product architect, a social chair, a strategist, a tactical guerilla fighter, a human shield against distractions, a cheer leader, a measurer and communicator of team performance (whether good or bad), a translator of corporate strategy to his/her team, and a translator of technical jabberwocky to less technical stakeholders.

He/she must take care of his/her product as well as people. He/she must work effectively with product management, sales, marketing, manufacturing (for hardware products), finance and operations to ensure the output of the development team plugs into a viable and implementable company plan.

How do you measure the performance of the development manager? Which aspects are the most important to watch?

There is no right answer to this question because the hat prioritization depends on the organization, the state of the product development process, the personal dynamics inside and outside the development team, and the personality and style of the development manager.

For me, under most circumstances, the success of my team defines my own success. There are two areas to watch:

Team performance: Is the team hitting its milestones on execution and developing a great product effectively and efficiently?

Team development: Are we nurturing and empowering team members to grow and prosper in their respective careers?

Team Performance
The greatest compliment anyone can give me and my team is to tell us that we are an execution machine. A team that performs well and executes its initiatives is a team that shines.

Now how do you create conditions to help your team excel? First and foremost, the right people must be in the right jobs. There’s no way to get excellent performance out of an organization if people don’t have the right aptitude and training to do the job they are asked to do in the time frame that the job needs to be done. Performance will also suffer if people are made to do things they don’t like to do for extended periods of time.

Second, we must clearly define goals and objectives, and then stick to them for long enough so the team has a chance to execute against those goals. To be in a startup is to be in flux. New data and learnings flow in all the time and we do need to be able to stay nimble and pivot rapidly when the data tells us to do so. That said, continuous thrashing is the best way to trash a team’s performance and morale. We must strike a balance between our desire to turn on a dime and our need to stay focused so we can execute against the best available information, creating deliverables that will help us test and learn for the next iteration.

Lastly, we need to succinctly define success in a clear and tangible way, then measure the team’s performance against these success metrics. What you can measure you can improve. There is nothing more motivating than being able to celebrate victories when we hit our milestones. And when we miss, those are learning moments that give us valuable data to help improve our performance the next go-around.

Team Development
The second thing to watch for is whether team members feel happy and supported in their jobs, and whether they are growing and prospering along their chosen career paths.

I take the coaching aspect of a development manager’s responsibility very seriously. To the extent possible, the development organization should provide opportunities for team members to learn new things and stretch their skills in their areas of interest.

While I believe the primary characteristic of a high caliber development team is its performance, a happy, motivated team in a trusted, supportive work environment that looks out for their interests and takes steps to help them grow can usually get more work done faster and with a better quality of output.

What do you think about all this? How would you prioritize these hats in your own role?

Bringing up a new web app is much more than a technical project management effort. Any new product or service development program is a massively interdisciplinary exercise. In order to have a successful outcome all affected constituencies will need to be involved in developing the program plan, so that key milestones and dependencies are identified from the get-go and actively and aggressively managed so that there will be no surprises halfway down the line that will result in a significant project delay.

Here are some of the interdepartmental milestones that need to be worried about for our consumer SaaS example.

Basic product roadmap developed with some idea of phasing of which problems to be solved when and how over the next 12-24 months (I like to make a 1-2 year actionable roadmap and a 5 year vision roadmap)

First pass definition of minimum viable product (MVP) complete (this is a hypothesis based on customer learnings to date)

User stories developed (this usually requires a second round of customer research) – a paragraph per story

Key user workflows fully mapped out at least to the flow chart level (this is particularly important if you are developing something for a target user persona that is not readily relatable by your program team.)

On the design side: (these milestones are specific to my consumer SaaS example. Some other day I will write a different post for hardware products.)

Determine high level navigation architecture (what are the organizing principles of the information and actions you can take on this web app?

Wireframe key pages to illustrate workflow

Design a few example pages to “put the breadcrumbs closer”

On the technical side:

Development platforms chosen

Server side architecture design finalized

Server set up, ready for development

First proof of concept with rudimentary UI showcasing any high risk items that needs to be investigated (e.g. if you were testing out a brand new private video streaming service that has just come on the market)

Intermediate internal releases as parts of the app comes up for testing

First instantiation of the MVP (minimum viable product) with a relatively complete user experience, released for beta testing

First release of the MVP (start to charge for the service!)

On the customer research side:

First set of product discovery interviews done, ready for persona development

User workflows vetted with users at the wireframe/storyboard level

Customer Advisory Board (CAB) assembled, ready to advice program team on features and benefits

Continuous testing of intermediate releases with CAB members

Usability study of implementation for key workflows (Do some in-house lab testing with fresh subjects – not CAB members, and do some across a broader audience with services such as www.usertesting.com)

Develop PR strategy to get the word out (for this example, work should be done well in advance to get key blogs to cover the launch of the web app. Facebook page should be set up with appropriate content and prepopulated with fans drawn from the early tester community.)

Update any corporate web pages ahead of time for a coordinated launch activity

On the business development side:

If applicable, business development activities to land partners will need to carry on in parallel with all these other activities. For instance our music app for small children might benefit from having Suzuki string teachers on the roster to provide expert answers. The business development activity for this app would then involve recruiting and engaging these partners.

Develop on line help / FAQ (this could be done entirely via a searchable, hierarchical knowledge base)

On the legal / regulatory side:

Develop end user license agreements / terms of use

If applicable, obtain regulatory clearance if the product or service requires it (our example does not require anything, but a medical site that, say, provides diagnostic guidance to various illnesses might have to look into FDA 5(10)k)

There is a lot of work that goes into developing a new business and many different constituencies are involved. A little bit of planning up front goes a long way towards helping to make the program a success (and to minimize the level of stress in the development process).

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
I’ve been working with students quite a bit at the MIT Entrepreneurship Center this semester. One class of questions that keeps coming up surrounds how you actually take an idea and make something out of it. In particular, lots of technical people know how to do the bleeding edge research and get something up and running for the first time, then they get stumped at the point where they have to take an idea (represented in, say, 3 powerpoint slides) and a proof-of-concept technology demo, and take it all the way to V1 release.

Before you start any development work, it is important to frame the program from a business case and financial merit standpoint. The first question to ask is, what is the objective of this whole thing? Whatever the product or service you are trying to develop, you need to have a clear idea of what you are doing and why, and for what set of customers. You also need to clearly understand what you and/or other stakeholders like investors, partners and customers can expect to get out of it. If you haven’t figured that out, you are developing a technology, much less a product or service and especially not a new business around your proposed offerings.

Let’s take a new web based business as an example. Suppose we hypothetically say that “this whole thing” is a novel B2C consumer SaaS play. Some questions to ask at this stage include:

What is the market segment you want to target and why? (This forms the basis of your total available market)

What are the market problems of this target segment that will drive them to adopt your new offering? What problems are they facing – where are the pain points?

What are the defining characteristics of this segment (e.g. demographics breakdown, typical education, household income, all that good stuff”

What is the size of this market segment (by headcount, company count or some such – not by dollar amount)?

What is the product concept to solve this problem at the 50,000 feet level?

What is the likely size of the subsegment that will be addressable by the way you propose to solve this problem? (This forms the basis of the addressable market. For instance, if your offering involves an iPhone app, then your addressable market becomes the part of the target segment who owns an iPhone. Your total addressable market becomes limited by the penetration of someone else’s product or service.)

How are you proposing to charge for your product or services?

Now put the market sizing information, the pricing structure and so forth in a spreadsheet, run it out for 5 years and do a quick model to see whether you think the economics make sense. Don’t spend more than 30 minutes doing this – the purpose is to use this framework to help you think through factors that matter in the business case. This spreadsheet is mostly worthless as a tool to predict how your business will work because you have insufficient data at this point.

Having done all of the above, are you still happy with your idea, who you are serving and what you and other stakeholders will get out of x months of hard work and $y of investor money?

Now we all know the term “MRD” (a.k.a. “Market Requirements Document”) is no longer in vogue. Everybody wants to be fast, agile and not be tied down with piles of documentation. MRD is associated with the waterfall process and that’s very much frowned upon in this day and age. However, in my opinion you just don’t go into any major new initiative without doing some of this due diligence. I am against writing a large 35 page word document, but I do very much support thinking through these key points, gathering any and all facts you can get your hands on, and putting it all together in a powerpoint presentation, and using that as a communication vehicle to achieve alignment at all top level. Without this alignment a development program is pretty much doomed from the get-go – the engineers in the trenches could be working on large sections of code that are based on false assumptions and it would result in nothing but aggravation and frustration in the end.

Only after you have answered the above questions should you proceed to the development stage (which includes product requirements gathering, specifications, design, wireframing, then finally, coding. Coding comes last.) If you go through this thought process and can’t come to terms with what you find out, you should revamp the assumptions that led you to this new offering and pivot or adjust.

Now it is perfectly acceptable to go through this exercise and say “but we don’t know” or “the financials really doesn’t matter because this offering is a hook to help acquire customers for another more lucrative business”. But there is every difference between rushing ahead to do something without thinking through the implications and going into something knowing all the assumptions and facts. I’m a big fan of the latter – it usually leads to better results.

There is a lot more to discuss on how to go about answering my bulleted questions and how to actually plan and execute the development portion of the program. I will be filling in those posts over the next few weeks.

Like this:

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]Silicon Valley Product Group recently published a fabulous article on consensus versus collaboration. You can read the article here.

The article quotes a great line from Seth Godin: “Nothing is what happens when everyone has to agree”. I often see an excessive need for everyone to agree in companies big and small. Some leaders confuse consensus with collaboration. They feel that unless there is consensus, they cannot move on.

This is a problem because people on a team can have strong convictions and opinions. In situations where there is no obvious right or wrong answer, an otherwise good team could get stuck. People with fundamentally incompatible points of views get trapped in their own positions, which they continue to expound without stopping to listen to each other. It is up to the team leader to facilitate dialog and guide the team to consensus, and if that doesn’t work within a reasonable timeframe, to put a stop to this and make a call. Otherwise the team will stay stuck and get nothing done.

Team members in a well constructed, reasonably diverse cross-functional team will bring different perspectives to the table. That’s good. We want and welcome a healthy debate because it helps us consider the facts from multiple angles. However, the final decision rests with the person in charge of that decision, even if it will make part of the team unhappy.

In the words of my friend Agnes, who once served as the CEO of a small investment bank: “I’m not here to win the popularity contest.” To lead is to have the courage to make unpopular decisions from time to time. Good leaders make sure everybody’s voice is heard, make the decision, agree to disagree, and move on.

If you are part of a group where someone else made a decision that you disagree with, you should by all means share your concerns in a professional and constructive manner. Make sure your facts and rationale are presented and understood. If it is important enough to you, state your dissent opinion on the record. Agree to disagree, then get behind the decision and pull your weight in implementing the plan of record. You shouldn’t expect any less from yourself or anyone else in your team.

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
You just got funding for an aggressive new project, and are looking to fill some mid to senior level open positions. You have written the job specifications (don’t even think of starting the hiring process until you have that in hand). Who are you looking for: someone who has done the job before in a relevant domain, or a talented generalist who can be trained to do anything?

My answer is that it depends. There is a time for everything: a time to hire domain experts, and a time to hire best athletes. I have hired, and have been hired, as one or the other at different points in time. The question is how much of a tearing hurry you are in.

I once had the privilege of hiring several best athletes to build up a cross disciplinary research and advanced development team from scratch. This team was not tied to mission critical product releases. The most important attribute I looked for, other than their respective functional disciplines, was creativity and versatility. I needed quick studies who enjoyed being stretched. My team sported some of the best problem solvers I ever met. None of them had domain expertise, and it didn’t matter. I had plenty of time to teach them what they needed to know. It was great fun working with this team and we were very successful in our pursuits.

In another instance, my company had just landed a $1.5M funded development project with an aggressive schedule. We started a targeted search to staff the project, where we screened out anyone who didn’t have experience in an obscure branch of computer graphics. We rapidly ran out of people who met our stringent screening criteria. The last addition to the team was a “best athlete” – an excellent programmer who didn’t know computer graphics. For all his stellar track record, he simply couldn’t keep up. There was no time for him to learn what he needed to know to succeed. The fault was ours for forcing a fit. In the end, we regretfully parted ways when his contract came up for renewal.

Training someone to do something they’ve never done before is a transformational experience for both the mentor and the mentee. But you must have the time and space to do it properly. As a hiring manager, I feel that it is a breach of trust to the employee to put them in a position where they neither have the necessary skills nor have enough time to learn it on the job. It is equally a breach of trust to the company and its shareholders for spending valuable time and resources attempting to cross-train someone who is not right for the job, when deadlines loom and a project delay or failure has catastrophic consequences to the business.

Generally, if time is of the essence, I err on the domain expert side. People who take the time and energy to become experts in their fields frequently turn out to be fantastic all-around athletes too. That would be the best of both worlds.

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This time of the year, we get to hear all about everybody’s New Year Resolutions. I shall lose some weight! I shall exercise! I shall spend more time with family! I shall volunteer! I shall learn the trumpet!

These resolutions have fantastic mileage. Most people can recycle last year’s resolution every year. This is because those lofty goals fall victim to vision without execution. Without an actionable plan and a commitment to execute, these good intentions end up going nowhere.

The importance of execution is often overlooked in a startup where fluidity, creativity and innovation define “cool”. The need to be nimble and quickly pivot can create an environment where visionaries thrive, but execution is glossed over. But if execution is ineffective, even the best idea will fall down. In this brutal economy, if you cannot execute on the milestones attached to a funding round, you may never get a second chance. Your next appointment could be with the repo-man.

How do we set up an environment where our team can execute with excellence? Here are some tactics that have worked for me.

Clearly define the goals, objectives and measures of success, and communicate it up and down the foodchain.

Having enough an actionable plan to get started and go for at least the first phase (which should last weeks, not days).

Continuing to refine and build on the plan as you progress.

Construct the right team with the right skillset to get the job done.

Be ready to swap out team members if they turn out to have the wrong skillset or the wrong mindset.

Measure yourself against success metrics early and often and call a spade a spade as soon as enough data is available.

Celebrate victories, big and small. Reward team members for a job well done, early and often.

Hold yourself accountable. Own up to failures yourself – don’t make excuses, and don’t wait for someone else to notice.

Be open and humble. Talk less and listen more, to tap into the wisdom and experience of other people.

What are your favorite tips for execution? I’d love to hear your thoughts.