Archive for the 'Small business' Category

Work hard and play hard

A few months ago I wrote a post on cultivating a sense of community in the workplace.  I talked about the importance of socialization in a team.

This is easy to understand in the abstract but hard to get right in real life.  How do you balance productivity against community building?

Here are some signs the company is spending too much time on mandatory socialization.

  • Everyone in the company is required to spend over 4h each week on mandatory, company-wide events designed to “facilitate communication” or “build morale”. That is 50% of one (mythical) work day (and 10% of your potential utilization).
  • Organizers of these events do not consult others relative to the timing of these events, and push forward in the face of deadlines and milestones.
  • It has become socially unacceptable to miss “optional” events, even if folks can’t absorb the lost time (and then they have to put in nights and weekends to make it up).

As Dilbertian as it sounds, a company exists to maximize shareholder value, not to serve as a social hangout.  An environment that favors “fun” (real or contrived) over hard commitments and important deliverables is in questionable territory.

That said, companies can easily err on the side of all work and no play.  Some signs that a company is doing a terrible job with its culture:

  • You feel a chill in your bones each time you enter the building.  The chill stays with you throughout your workday (regardless of the state of the HVAC system).
  • You can’t name the significant other of a single coworker (and most of them are in a relationship).
  • You actually don’t know who’s in a relationship (and you’ve worked with the same people for 5 years).
  • You feel intensely uncomfortable at company picnics where you need to mingle with coworkers.

Getting the right balance between work and play is tricky.  The best that we can do is to strive for a good balance most of the time.

All I really need to know I learned in elementary school

Peter Bregman has a recent post about being inspired by his 4 year old to minimize the time spent on difficult transition times in the workplace.  This is so true (both in the preschool dropoff context and in the workplace).

Along the same vein, there are many management lessons to be had by studying the crowd management skills of my kids’ teachers.  Here are some of them – enjoy.

School rule #1: Can’t say can’t play.
When my oldest child was 4 years old, she became friends with a little girl who was part of a 4-girl clique.  This little girl explained to my child: “I can’t play with you because A, B, and C are here and I can only play with them. But B and C are not here Thursdays.  So if it’s a Thursday, and A is busy doing something else, and I’m not playing with anyone else, then I can play with you.” (OUCH!)

The preschool teachers have seen this before and they knew exactly what to do.  They divided the cliquey girls so they never sat together in class.  They manufactured team activities that required co-mingling them with everyone else.  They manufactured more activities that are led by kids outside the cliques.  They put anyone who excluded anyone else in timeout.

Key takeaway: make sure there’s a single, inclusive culture in the workplace.  Divisive dynamics isn’t something to be swept under the rug.

School Rule #2: “No, go, tell”

To keep kids from becoming tattletales, the teachers have a 3 strikes rule. The first time kid A does something bad to kid B, B is to tell A to please stop the behavior.  The second time, B is to depart from the scene and find something else to do that doesn’t involve A. The third time, B goes and tells the teacher.

Key takeaway: encourage folks to talk and work things out, and hone their conflict management skills.

School rule #3: “The 3 D’s”

Our elementary school has a “3 D’s” rule, which are exceptions to the “no, go, tell” rule: if a kid engages in behaviors that are dangerous, disruptive, or disrespectful, don’t wait for the first two strikes – tell on the kid immediately.  If a kid keeps on engaging in these behaviors, he or she becomes separated from the group.  For instance, there are two boys I know who currently “have their own offices” and never sit with others during class.  The needs of the other kids to do their work trump the disruptive kid’s need for inclusion.  If that still doesn’t work, the kid goes off to the principal’s office.  If that still doesn’t work… well, there are many other schools in the town.

Key takeaway: if someone is being disruptive or disrespectful, deal with the behavior in the moment, as the behavior unfolds.  If the behavioral pattern persists, separate him or her from the team and find something they can work on by themselves while working on the behavioral pattern, even if this reduces that person’s potential to contribute. If nothing works, regretfully, one would have to let them go.

Beta programs

This is the eighth post in my Customer Research series.

What is a beta program? The Wikipedia has the following definition:

“Beta” is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.

In my mind, the beta program provides an early window into how the market will receive the product release.  It generally happens at the very end of the development cycle.  I generally run small-scale beta programs as follows:

  • Recruit 10-20 beta testers to match the primary and secondary personas that the product is designed for
  • Do a kickoff meeting (either one on one or in a group) to set expectations on what’s in the new release, and how we expect to collect feedback from beta testers
  • Ask beta testers to use the product in the target environment of use
  • Schedule a call with each tester on the phone 1 week into the program, to ensure everything is going smoothly
  • Use phone calls and email to keep track of progress during the program
  • At the end of the beta program, schedule a phone conference or an in person debrief to collect feedback.

Since beta programs occur at the very end of the development cycle, typically weeks before the target release date, it is really only useful for testing things that can be iterated right before the release: positioning and messaging, delivery and support mechanisms and the like.  There is a great recent post on beta programs by Dave Daniels of Pragmatic Marketing that outlines all this – do take a look, it brings into sharp relief many of the questionable practices a lot of software companies take for granted.

Findings from beta programs can also be used to pull a release if (gasp!) a customer discovers a fatal bug that the QA department failed to find.  Lastly, it can also be used as a vehicle to collect customer feedback for the next release.  It is NOT a vehicle for usability testing – it is way too late in the game for that!  Usability studies (whether in lab or extended use tests) should be done early in the development cycle, before the product is finalized and when there is still time to effect change.

Using beta programs to test positioning is a great idea.  One can save a lot of money in marketing programs by iterating the messaging with target buyers until winning messages are arrived at.

When is a startup no longer a startup?

When is a startup no longer a startup?  Is a company looking to scale its business a small business operating at a loss, or a startup in search of growth?

It seems that there is no commonly accepted definition of the term “startup”, as evidenced by this FAQ from answers.onstartups.com.

For me, I prefer to think that a startup becomes a small business once it has evolved a business model, acquired a substantial number of customers, is at least somewhat dependent on the resultant revenue stream, and is feeling a need to scale.

Now why do we care about this terminology?   It’s because “startup” and “small business” evoke completely different images and expectations on the proper way to conduct business.  A startup’s charter is to experiment and learn until it finds something that works and has lasting value.  A small business must keep its existing business model going while investing in new innovations.  Naively applying startup thinking to a small business or vise versa could very well result in a suboptimial decision making process.

One place that really matters is the pivot. A startup, with a small number of customers, can rapidly iterate on learnings from the market, and pivot on product strategy, offerings, positioning / messaging, and go-to-market strategy without worrying about alienating a large customer base.  A small business, however, has amassed substantial numbers of customers that it cannot offend (having no alternative customer base to help maintain its revenue stream). Thus it must keep a certain level of staff for baseline development, sales and marketing and customer support activities, just to stay in business.

So the small business can still pivot, but the scope of change is more constrained. It can iterate on positioning / messaging and go-to-market strategy, but changes in product and service offerings must take on a smaller scope and/or a longer timeline.  Of course, ultimately whether a company can pivot and change course quickly depends on their cash situation… a small business with a large war chest can well out-pivot a startup with low cash reserves.

So is it good or bad to have made this transition?  I for one think it’s great news.  It means the company is one step closer to nirvana – becoming a successful business and bringing lasting value to customers.  It’s a great time to be with a company!

Add to DeliciousAdd to DiggAdd to FaceBookAdd to RedditAdd to StumbleUponTweet this

Using detailed interviews to build personas

This is the fifth post in my Customer Research series.

There are many awesome posts on personas, including this primer by Steve Johnson at Pragmatic Marketing, and this post about how personas serve the CEO and the executive team.  So I am not going to belabor the point.  I’ll simply provide a case study of exactly how I go about building personas.

Before we begin, we must decide whether we are building buyer personas or user personas.   Since I have always worked on the PD/PM side (instead of the PMM side), I almost always end up making user personas first.   Here is the process I use.

1.  Pick a market segment.  Size it.  Make sure the total addressable market (TAM) is big enough to matter.

2. Generate prototype personas.  Draw on your company’s tribal knowledge / theories about customers and prospects, as well as from your own life experiences for this.  Make sure you state assumptions about needs, wants and expectations.

3. Create a screening questionnaire.  Work with a recruiter to find subjects.  Evolve screener as necessary (tweaking the prototype personas as needed).

4. Plan the interviews.

  • Pull together the equipment: a mini DVD camcorder, a tripod, fully charged batteries, camera, laptop for notetaking. (Mini-DVD camcorders result in the least postprocessing overhead.  Finalize the disk and you can watch it instantly.)
  • Staff each interview with 1 researcher who will lead the conversation, and at least 1 support person (in the role of audio/video monkey and notetaker).
  • Every researcher should plan on going to several interviews (overlapping with each other for some of them).
  • Cycle as many staff members through the support role as possible. This exposes everyone to the process and gets people out of the office and into customers’ environments, which is always good.
  • Plan mid term and final debrief sessions with the research team.
  • Plan other work around this work.  It takes at least 1 – 1.5 person days to process each interview. You also need time to reflect on the results.  Expect each researcher to be completely consumed for a good 75% of the time.
  • Share intermediate work products with the team early and often.  Transparency is key to buy-in.

5. Do the interviews. Here are some tips I’ve collected over the past 14 years (your mileage may vary).

  • For best results, detailed interviews should be done in the target environment for product use. That said, an interview at a coffee shop or some other neutral environment is better than no interview at all.
  • Start with an introduction and a warm up section where the subject gets comfortable with the researchers, then ease into the topic of interest.
  • Keep the interview guide short and sweet. Questions should be open ended, inviting the interviewee to talk in their own style and to show their personalities.
  • Be prepared to take the conversation where it wants to go, not where you want it to go.
  • Make sure the subject talks more than you.
  • For certain types of products, you may have to match gender. (e.g. research around a feminine hygiene product will require a female interviewer).
  • Don’t even think about showing a product or product concepts. Discuss your product at the end only if there’s time left over.

6. Build the personas.  With luck, you will have recruited carefully to get the right people, and after 10-20 interviews, they will have self-organized.  You should now be able to build composite personas in each bucket of subjects who share key needs, wants, expectations, and attributes.  Check these personas against the people you met and tweak until they work well.

Once the primary, secondary and non-personas are built, you can begin to use them as a proxy to help you envision what benefits they require, what products or services can deliver these benefits, and how those products and services may look like.

Add to DeliciousAdd to FaceBookAdd to StumbleUponAdd to Twitter

New Year’s Resolutions

Happy New Year!  Here are my New Year’s resolutions.  What do yours look like?

  • Live more in the moment and enjoy what we have.
  • Celebrate small victories.
  • Spend more time listening and less time talking.
  • Pause longer before reacting.
  • Socialize and help facilitate socialization at work while maintaining productivity.
  • Make professional development plans for all team members.
  • Make good enough decisions based on good enough data, then iterate.
  • Make it easy for everyone to keep the main thing the main thing.

Top startup articles from last week

Financial modeling for a new product or service

I don’t have an MBA. I have never even taken an accounting class. Yet in my years as a product person I’ve had to help generate numerous financial models to help figure out whether a new products and/or services makes economic sense.   Through my mentors, I learned just enough to generate the tables and charts that would show me whether the product or service deserves to be built.

In my mind, financial modeling for a vaporware product is a framework to help the team think through these questions:

  • How many units do we think we can sell in the next few years?
  • What is the average sales price?
  • How much does it cost to sell each unit?
  • How much do we need to spend to develop and sustain this business?

The toughest question to answer is the unit projection question.  Some people pull projections out of you-know-where.   I think a little analysis goes a long way here.  I tend to do this with a top-down approach, then cross check against a bottom-up approach.

The top-down approach is a market sizing and analysis exercise:

  • Use analyst reports and other sources of quantitative data (e.g. US Census) to size your target market segment.
  • Take it down as necessary to accommodate constraints imposed by your technology platform.
  • Come up with a percentage ramp that predicts the market penetration you will achieve over time.
  • Cross check your projected market share growth against competitors (quarterly or annual reports from public companies in adjacent or comparable markets are a great resource).
  • Apply the sniff test: do you think you can sell enough to make this product worth your while?

Once the top down approach passes the sniff test, you can try the bottom-up approach:

  • Build up the number of units you think you can sell via each distribution channel in the plan.
  • Use hard data as much as possible – for example, if you are selling through retail outlets, check your projections against sell in/sell through data for comparable products through those outlets or classes of outlets to make sure your estimates are not out of whack.

Now that you have your top down and bottom up number, compare them and see if they match.   If they don’t, figure out why.  It may be that your top-down scenario is too rosy and the channels are fundamentally not equipped to support that kind of volume. Perhaps the distribution strategy needs to be revisited.  Or it may be that your channel projections are too rosy and assume an unreasonable growth in market share.  It’s an iterative process until both approaches pass the sniff test.  At this point I would use the bottom-up estimates as a basis to calculate gross revenue projections.

Having a credible unit sales / gross revenue projection is half the battle. The other half is to figure out whether the economics of the business makes sense. This is where the value chain analysis comes in.  Lay out everybody in the product’s ecosystem, figure out who gets paid how much and by whom, tally up all the costs out of your own business and calculate the cost of sales.  At this point, you are ready to calculate the gross margin of the product based on the expected average sales price.

Lastly, let’s count all heads and operating expenses directly attributable to the new business line.   There is the upfront cost (to develop the new product or service) that skews towards R&D.  Then there is the long term cost where R&D spending goes down into maintenance mode and sales and marketing costs go up to fuel growth.

Once all this is done, it’s time to tally it all up and make a nice hockey stick picture – the net income chart.  Typically the income will go up exponentially a couple of quarters after the product or service is introduced.   If it doesn’t, figure out why.  If you can’t make the net income look reasonable, perhaps the product or service doesn’t make sense for your business after all.

Contractors or permanent hires?

In this uncertain economy, a startup is often caught in a Catch 22 situation when it comes to staffing and team building.  What do you do when you have a lot of work now, but you cannot predict whether the work will be there in 6 or 12 months?

Nobody likes to let good people go.  A decision to take on a permanent new hire is not something I take lightly.  To avoid hiring on spec, a lot of people turn to hiring consultants or contractors to get the work done while mitigating risk.  The thinking is that we can plug the current need with contractors now without resulting in a long term bump in the company’s operating budget. If the work stays and there is budget for it, wonderful.  If not, no hard feelings – we simply part ways when the work goes away.

This method can work wonders, but I have seen it being taken too far.  This is particularly problematic if some specific and esoteric domain knowledge is required to build the product itself.  So the next time the company needs to get something done, they have to incur the learning curve all over again.

I believe in striving for balance between the conflicting needs of not over-hiring and not building core competencies. I like the following model:

  • Hire contractors with domain expertise to address specific and transient project needs
  • Hire excellent generalists to become permanent members of the team. Do temp-to-hire if possible so we can test-drive the relationship and make sure the team member will thrive in the company in the long run.
  • Have the contractors work with in-house staff to complete their projects.  The project is done as quickly as possible, the in-house staff is cross trained in a new area they are unfamiliar with, and the company gets to build up its core competencies. It’s a win-win situation.

How have you addressed this challenge in your company?

Top 10 startup articles of the week

Next Page »