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.

On diversity

Diversity in high tech is a hot topic these days.  Well known bloggers like Vivek Wadhwa, Brad Feld, Eric Ries and the guys at Venture Hype have been trying to advance the case for women in technology.

As a woman in a male dominated industry, I find it both funny and depressing to watch these powerful men speak up for the women.  I only wish an equally powerful woman could have told our side of the story!

Gender issues aside, Eric made many great points about why diversity matters.  Here is a quote that I particularly like.

One of the most pernicious effects of groupthink is the sense of entitlement it breeds. Teams that are complacent are less likely to challenge their own assumptions, less likely to listen to feedback and, therefore, less likely to learn.

This is absolutely true.  I see this phenomenon everywhere.  Teams that are all the same gender, or race, or age, or economic circumstances, all tend to think alike.   Since they are all so alike, they project themselves on everyone else and remake the world in their image.  It’s a lot harder for teams like that to understand what it’s like to be someone else. This hurts when they are designing products and services for someone else.

A little diversity goes a long way in shaking up this complacency.   It makes people uncomfortable.  It rocks the boat.  It makes people think and wonder.  It makes it a little easier for folks to realize: People are Different.  And that’s the beginning of the end of arrogance.

Show up on time

I just read a new post by Dan McCarthy from the Great Leadership blog about how being on time is an important attribute of a good leader.  I could not agree more.  Being late (or worse, being AWOL) says a lot more about who we are than we realize.

  • If we are habitually late, we are telling people that we disrespect their time.
  • If we are always on time for meetings with big kahunas, but are habitually late to meetings where we ourselves are the big kahunas, we are telling our team members that we respect our rank more than we respect them.

Lateness in deliverables also communicates disrespect.

  • If we are habitually and substantially late with our deliverables to other team members, despite a clearly defined schedule everyone agreed upon, we are telling people that we not only disrespect them, but we think little of our commitment to the projects we are working on with them.
  • We are teaching people not to trust us when we promise anything.
  • Over time, if people have a choice, they will try to avoid working with us altogether, since they can’t get their job done if they have to depend on us.  It doesn’t get much more career limiting than that.

Punctuality is a window into our core values.  We should all watch what is showing through that window.

How to have productive meetings

Saeed posted this pie chart on the On Product Management blog some time ago:

I’m sure we can all relate.  The worst part is when people arrive utterly unprepared, despite a painstakingly prepared pre-read package you send out 1 week in advance.    People are busy.   Sending out materials doesn’t mean those materials will be read.

How can we make meetings productive?  If the meeting is important enough, it is time for a lot of pre-meetings to set expectations and go over any background materials that people need to digest beforehand.  The more important the decision to be made, the more work I do at the one-on-one level.   No one should be surprised or unprepared, and it’s up to the meeting organizer to take care of that, even if it involves reverting to the oral tradition.

Pre-meetings take a lot of time for the meeting organizer, but the collective time spent on the process comes down dramatically, and the meeting itself becomes efficient and effective.   The time spent is definitely worth it.

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.

Beware the focus group of one

I read a great post by Jeff Bussgang (an entrepreneur turned VC) where he talked about “Mother in law market research”.  He shared a quote by his MBA classmate:

“I think [this consumer product] will be a hit because I can see my mother-in-law buying it.”

I don’t have to explain why such an assertion should never be made without supporting data (e.g. does the MIL match the primary or secondary personas?  Does she have the right demographic / psychographic profile?  Was there qualitative and quantitative research to prove the same?)

The “focus group of one” happens to the best of us, regardless of our roles.  Sometimes we use the MIL, most times we project our own views onto the target personas.

It generally goes like this.  Someone in the company becomes fixated to some product feature.   99% of the time, he or she is not a good match to the target personas.   (He can be a man commenting on a product to fix hot flashes for menopausal women.)  He or she would share his/her opinion:

“Yesterday I saw a demo of <product feature>, and it immediately made me think people can <achieve improbable application of product feature to unrealistic use case>.  I am now absolutely convinced we must line up all our resources to optimize the user experience for <unrealistic use case> because if I thought of this,  lots of other people would want to do that too.”

I’ve seen it happen to  founders, CEO’s, CTO’s, COO’s, or SVP’s of something-or-other.  For all their brains and success (present and past), they fall into the trap of believing they can project themselves into the minds of target end users, without taking the time to really understand the latter.

Unfortunately, these guys routinely underestimate the magnitude of thrashing they can cause.   Let’s face it, if the SVP Sales declares that product feature X must do Y, the product team isn’t going to spend 2 minutes convincing her otherwise.  Instead, it is going to spend 2 business days putting together a well structured argument, based on facts.  Then they will make an appointment with her to present their arguments.   They may even commission a new research study to put the argument to bed.

And let’s face it… if she remains unconvinced despite hard facts, and the company is set up in that way, Feature X shall do Y in the next release.  Forget about the research results and the needs of the end users.

So, to folks on the management team:   please don’t become the focus group of one.  At best, you will waste much more time of your product team than you realize.  At worst, your stray comments could cost your company its ability to develop great products.

Positioning statements

There are many templates for positioning statements, and different ones exist for brand, product and services.

Being a product person, I must admit that I really only care about functional positioning statements for products or services.  I am partial to the product version below (courtesy of GrowthConnection):

Product Position Statement

For [target end user]

Who wants/needs [compelling reason to buy]

The [product name] is a [product category]

That provides [key benefit].

Unlike [main competitor],

The [product name] [key differentiation]

Just for laughs I am going to apply it to a fictitious product that I would love to buy: a miniature kitchen composter that doesn’t take up much space, requires no worms, maintains a high core temperature purely from absorbing energy from the lights that are on every night,  and doesn’t smell at all.

For consumers passionate about the environment,

Who practice green, sustainable living in every aspect of their lives,

The magic composter is an indoor composter

That provides a fast, odorless way that sustainably converts all your kitchen waste into compost every day, 365 days a year.

Unlike the Worm Factory(R),

The magic composter has the footprint of a 2.5 gallon trash bin, emits no odor, can keep up with the kitchen waste of a family of 6, costs only $15, and requires no worms to operate.

Now I am sure my magic composter needs lots more work, but that’s the idea.  This format forces you to think about why the product exists and what it does for the target persona. I love it.

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

Top smartphone articles from last week

Next Page »