Category Archives: startups

Customer Interview For Product Discovery

Conducting customer interviews is a great way to validate, or invalidate, your product idea. Interviewing potential customers is almost always a cheaper and faster way to learn what your customers’ needs are, compared to building the product first and then discovering that you built the wrong thing. Even with an existing product, you can discover which new features will be most valuable through customer interviews. Here’s a great video that explains how to do it.

Share it!

Want a smart team? Make sure it gets the recommended daily allowance of estrogen

A team without a woman is like a bicycle with… some fish? So it would seem, according to Grace Nasri, who writes in the HuffPo about the gender gap in tech from an interesting perspective. She got my attention with a 2011 HBR story profiling research by Anita Wooley and Thomas Malone showing that the one significant factor that demonstrably upped the measurable collective intelligence of a team was the presence of females on it.

The HBR research shows that the intelligence of individual contributors is not a predictor of a group’s intelligence. And that in fact a team dominated by a bossy, know-it-all individual contributor (yes, even one who actually does know it all), will be outperformed by a team consisting of lesser lights. But the most statistically significant predictor of higher team performance wasn’t the intelligence of the members of the team at all, but the presence of at least one woman on the team. Read the HBR interview with the study’s authors to learn how they designed the study, including how they measured individual and team “intelligence.”

Nasri goes on to talk about the tech industry’s gender gap, writing that “The latest Midas List, Forbes’ annual list of the 100 top venture capitalists, for example, includes just two women,” and that “only 8 percent of new startups backed by venture capital included at least one female founder.” It’s not clear what is cause and what is correlation in these numbers–I don’t believe male VCs are overtly biased against women founders, and I think that cultural factors other than bias can account for some of the disparity. For example, I am pretty sure there are more extroverts than introverts on those lists, too, which can also be explained by our unconscious preferences for certain presentation styles–“male” styles and “extrovert” styles of communication tend to be received more favorably on first impression.

As a person who is very concerned with language, I also wonder if our use of “team” terminology, deriving as it does from competitive sports, leads us to unconsciously favor masculine, extroverted team members and the funding of teams that resemble the 49ers more than those that resemble sewing bees. Gender manifests itself in subtle ways that go far beyond sex, into culture, communication style and unconscious preferences. Our collective favoring of masculine styles of team participation is something that is more about norms than it is about biases, for example.

In 2004, when I was editor of a newspaper, I wrote an article for Inc. Magazine describing how I used Home Comforts: The Art & Science of Keeping House by Cheryl Mendelson, rather than the ever-popular The Art of War as my management bible. Funnily enough, on re-reading the story, I find my “feminine” approach to management sounds pretty agile. I think the advice I gave then of looking to the laundry room as often as you look to the war room for management models holds very true today, and supports the HBR study authors’ conclusion that what made a difference in team success was including a diversity of thinking styles. What do you think?

Share it!

What’s An Agile Paycheck Look Like? A glimpse into Agile Learning Labs’ new compensation model

What kind of agile training company would we be if we didn’t try to build our company from the ground up using agile methods for everything from team decision making to hiring to how we pay ourselves? Here’s how we arrived at a radical new way of paying ourselves. (Hint: if you’ve seen the heist movie Ocean’s 11, our team compensation model is a lot like theirs.)

Agile Learning Labs has gone from two full-timers to six in little over two years (plus an outstanding stable of independent contractors). In the beginning, of course, Chris paid himself nothing, as one does in a startup. I was the first salaried employee. I got a paycheck, while Chris got equity. As we grew, we added a commission-based sales position. To our great joy, this individual made more in the first year than either Chris or I had in the first three: this meant the company was up and running and making a go of it.

Cheaper, perhaps, but scrum says the ideal team size is 7, plus or minus 2.

We grew quickly from three to six—fleshing out our operations, marketing and training staff. In our haste and inexperience, we looked to the real world for our guesstimates on how much to pay people for certain functions—and then adjusted down for the startup nature of our business. The promise of more to come was sincere, but figuring out how and when was always on the back burner.

According to 37 Signals’ Rework, we waited just long enough: we didn’t address our compensation model until it started to cause us pain.

We finally addressed the issue when we hired yet another person, who came on board on the condition that we resolve our “compensation issues.” Sometimes it takes outside perspective to get things to move, even on the most agile team.

First, we looked at where we were now: how we were paying people, and why. We had cobbled together a mish-mash of salaries here, hourly wages there, percentages, commissions and training fees, all of which had been individually negotiated. Some people were being paid in apples, some in oranges, and still others in durians and bing cherries. It was an unsustainable mess. What to do about it?

Conventional wisdom wasn’t helpful. We realized that the more commonplace model for a company like ours—be it a training company, or an architectural firm, medical office or a law partnership—was emphatically hierarchical. At the top, you have your “rock star” performers, those who deliver billable services and are highly compensated for doing so. Below these you have a highly competent cadre of administrative back-end earning steady if middling wages. And below these, you have the “interns” who will someday be rock stars themselves, leap-frogging right over the hard workers. Teams like this have well-defined roles, a steep pecking order, and the longstanding resentments to go with those things.

Is your team full of Rock Stars? Hint: that might not be a good thing.

In most conventional settings, agile trainers are no different from most doctors, lawyers or rock stars. That is, they’re uniquely educated, talented individuals who made themselves what they are, and expect to reap the rewards of the risks they took to get to the top of their field. They cannot do it alone, however. It takes a whole team to run a training company. One trainer we know once referred to the entire back office as “just admin.” Well, some people watch way too much Mad Men.

On an agile team, Joan would be Don's equal--because she is.

You may only have met our bright, shiny trainers and coaches, but here’s what Agile Learning Labs’ back end really looks like: Our sales process is actually part of the training, as Steve doesn’t so much “sell” training as serve as a Dr. House-like diagnostician, figuring out what each client needs, and matching them to a trainer, coach or solution. It’s literally true that the diagnosis is half the cure, so if you wanted to, you could make a case that the trainers are Steve’s support staff instead of the other way around. Betty, to continue the medical metaphor, keeps the operation breathing much the way an anesthesiologist does. Then you have our “marketing” department. To again quote Rework: everything we do is marketing, and we know it. Our marketing guru is an internal coach as much as an external ambassador. And unlike any other training company we know of, we have a creative department that includes a fully-fledged publishing operation. When our trainers and coaches walk into a scrum room, they do so carrying a book on the topic, produced by an agile publishing company that we own. As a team, we are a remarkable powerhouse.

Ricardo Semler's book Maverick

So as a team, we dove in and did a lot of research on existing compensation models. We looked at the profit-sharing model used by Make Architects, at the democratic innovations afoot at Richard Semler’s Semco, at Menlo Innovations and The Hacking Business Model, and many, many more. But in the end, we were most influenced by… scrum.

Yes, to guide us in how we should think about compensating such a team, we thought we’d look at what we teach our clients about the nature of teams and incentives. We teach people to flatten their hierarchies, break down their silos, treat everyone as valuable, and to make sure this is true by building teams where all members have vital skills that mesh together. We teach them to give everyone a voice, to incent co-operation and collaboration rather than competition, to emphasize cross-functionality over status. We teach them that by empowering the people doing the work to decide how the work is done, you stimulate productivity.

Al gets a cut... not this Al.

So here is what we ultimately decided to try: Agile Learning Labs would pay its core team of six people equally. Period. We established a low base salary, to be paid out weekly. We set a base “cushion” or cash reserve for the company, an amount we needed to keep in the bank. Any profits above and beyond that cushion, would be divided by seven and distributed equally. (Seven? Agile Learning Labs, or “Al” for short, would get his cut, too, to grow the cushion.) We ran a lot of numbers, and came up with best, worst, and middling scenarios where this might land us all financially, and decided we were all more than willing to put our money where our mouths are. The operative word here is “try.” We plan on inspecting and adapting this new model frequently as we continue to work, thrive and grow.

Salaries? What a quaint idea! That's so last-millenium!

What this compensation plan has stimulated in the scant few weeks it’s been in place is amazing. We communicate better now, shooting email threads across the organization to discuss strategic decisions. We have begun to apply the concept of “business value” to everything we do. We started a backlog in order to prioritize projects, and every single team member has been speaking up more frequently across a far broader range of topics than ever before. The sense of shared destiny is palpable. The heightened sense of trust is profound, and mutes any accompanying notion of increased risk.

The risk is real. In the first month, every single person in the company made less than they did the month before, as we paid off lingering commissions and fees, and brought the cushion up to par. But at the same time, we could see that without those lingering debts from our old model, the same revenues would have given us each a comfortable month—and next month looks pretty great. Those of us who are finally enjoying a seat at the profit table feel immense appreciation for those who took a temporary hit in order to set us straight, but none of us are viewing it as a “sacrifice.” We’ve defined success as this: everyone makes more money this year than they did last year, including last year’s highest earning team members.

One of our operating values as a company is “Crafting engagements in which everybody wins.” So we’re betting on our new compensation model super-charging our productivity. We’re hoping that Agile Learning Labs, and all of its team members, contractors, students and clients will be better off than ever, now that we’re walking our talk in a whole new way. We’ll be planning, iterating, inspecting and adapting as we go, and we’ll keep you posted on what we learn.

Share it!

5 Agile Ways to Rock the Boat with Eric Ries

Eric Ries Interview by Lara Druyan at Hackers and Founders, July 2011According to Eric Ries, another way to say “agile” is “extreme troublemaker.” If you think you know what’s given, constant, and unchangeable – think again.

In an interview with Lara Druyan at a recent Silicon Valley gathering hosted by 106 Miles and Hackers & Founders – Eric poked holes in the foundation of entrepreneurial sense and sensibility we all “know” so well.

From his interview, my favorite five agile ways to rock the boat of status quo are:

1. Redefine Entrepreneurship.
Think you need to live on ramen noodles, sign your world over to venture capital, and camp in a garage to be an entrepreneur? Maybe not. In Eric’s view – entrepreneurship is a management discipline for creating value in an environment with a high degree of uncertainty. Entrepreneurship lives in large corporations, small startups, and nonprofits everywhere. And considering the high degree of uncertainty that pervades our lives these days – even my kitchen is a hot bed of entrepreneurialism as I ponder the uncertainty of what’s for dinner tonight.

2. Put your Idea up for Adoption.
Got an idea? Afraid someone else will steal it? Eric advises that surrounding your baby in a cloak of stealth will very likely be the thing that kills your idea. Stealth mode is like having a conversation with yourself. As an experiment, take your second best idea – and actively go out and try to have someone else steal it. Established organizations moored in the status quo won’t be interested. Other folks won’t have the juice to run with it. But talk it up – walk your idea like your favorite puppy. And when it grows up – it won’t bear the tiniest resemblance to your original doggy idea.

3. Loosen the constraints.
Ever hear the old adage of “Time, quality, money – pick two?” Fact or fiction? As someone who has regularly used this adage in previous corporate lives – I had never considered that maybe it’s not always true. Eric believes that the waterfall model of product development creates this “pick any 2” constraint, and by changing your process – you change your constraints as well.

4. Aim for Failure.
“Every failure is our most precious opportunity to discover what is true.” Create learning milestones, not product milestones. Listen hard for leap of faith assumptions. If you are assuming that your click-through rate on a given page will be 2% – don’t bury that assumption in a footnote on page 32. Print your assumptions in 97-point font and post them on your front door. Then test the assumption quickly and adapt. Interestingly, there’s a lot of failure in startups – except in the media where only success gets sold to Hollywood.

5. Visualize Success.
As an entrepreneur, success is having a vision of the world as a better place, and then building a sustainable business organization to fulfill that vision. It’s up to you to define what is a “better place” – more connected, better informed, entertained, you get to choose. Success comes from creating that vision and then failing your way to success.

ERIC RIES is an entrepreneur and author of the popular blog Startup Lessons Learned. He co-founded and served as CTO of IMVU, his third startup, and has had plenty of startup failures along the way. Eric’s first book THE LEAN STARTUP will be published in September 2011.

Share it!

What I learned at Startup Weekend SF: Agility is the state of nature

What's a good mother/son spring break activity? Why, going to Startup Weekend and spending 50 hours building a company with ten total strangers. Perfect because my 17 year-old vastly prefers the company of adults to that of other teenagers, and because he's been on the high school treadmill for so long that I thought it would be nice for him to see what the light at the end of the tunnel might look like–that the world of work can be a rather thrilling place.

Several years ago, I visited the very first Y Combinator class of college-age founders when they were only six weeks into their startups and was astounded at the number of fully functioning products. Turns out six weeks is an eternity, way more time than you need to build and launch a startup!

This weekend, 150 of us crammed into a giant room in Microsoft's Market St. facilities. We were given lots of food (thanks to Sana of Women 2.0) and very little direction. After a free-form round of idea-pitching, with coaching from the lovably dyspeptic Dave McClure (our team-member Han Pham describes his style here), we were cut loose to self-organize into teams.

Tyrone and I were interested in Connor Lee's idea for a venue-rating site for event planners (easy to build in a weekend), and Julian Bryant’s pitch for a site that would allow people to interact around pending legislation. As it turned out, Connor, who had legislative experience Tyrone and I all joined Julian, along with developers Marcus Phillips and Philipp Pfeiffenberger, SEO/Social Media/Web Marketer Aris Vlasakakis, marketing gurus Sherbeam Wright and Mariam Ishpahani, journalist Han and a couple of others who came and went over the weekend. Julian emerged as the natural leader, as well he should being a former Senate intern and Georgetown Law grad with a startup around language learning.

I have worked as an employee or long term contractor on three tech startups, one VC funded, one angel funded, and one bootstrapped. This team outshone them all in terms of raw talent, intellectual horsepower, organization, distribution of skillsets, commitment and efficiency. And we were not alone. In all, 23 teams had working demos or prototypes to share on Sunday evening, and a couple had actually launched fully functioning products (I was using Snoozemail in my gmail inbox before the evening was out). There could be no better demonstration of the power of self-organizing teams than this display of exponential creativity and productivity.

Marcus and Philipp–both Y Combinator alumni if I'm not mistaken–were curious about Agile, and we talked about it a little bit, but there really wasn't time to talk about anything but pushing our product out the door. What I found enlightening was that their native values, instincts and practices were inherently Agile. Being Web 2.0 guys who work in Ruby and Python, they have never been exposed to Waterfall. (The only team that did anything resembling a Waterfall process was the one team that had absolutely nothing to show on Sunday, having spent all their time creating specs.)

This makes me think that perhaps the best way to promote Agile is to take a cue from crime prevention and literacy drives: don't focus on reforming those who have already been "lost" to Waterfall methods; focus instead on preventing the destruction of our talent pool in the first place!

Our team, christened "Democlarity," divided rather quickly into two right-sized sub-teams (also quite Agile). Tyrone went with the bus dev side, working on business planning, market research and content creation, while I went with the development side–the first time I've ever worked on a project and not been the writer/editor. I did some HTML wireframing, then turned my attention to CSS styling while the devs blasted in the functionality.

We had technical difficulties here and there–the wifi broke, version control broke, my host account where I was hosting images while designing went down at a critical point. Marcus and I paired on merging the disparate html files, then Philipp and I paired on some last minute CSS (he is 10x faster than I am, so my main contribution was saying things like, "Can you make that greener?").

Everything  got done, and Aris and Marcus had time to practice their demo pitch. We weren't live online, but we were certainly way too cool for powerpoint, and were able to show a site with functionality and an amazing amount of depth.

Aris and Marcus rocked the demo, with Phllip driving the mouse so they wouldn't have to break their patter, and we disbanded feeling like we'd accomplished something fairly spectacular and been a part of something pretty important. The Democlarity team is looking forward to a reunion in a month, and plan to continue developing what we started in an open source-ish sort of way. In the meantime, a demo of our site should be up on fairly soon.

Tyrone went back to swim team practice today, and I'm back at work too. But I learned more about teams and teamwork this weekend than I did in the previous year–and that's a year in which I wrote an Agile training manual and helped organize the Orlando Scrum Gathering's Open Space Conference. I'd highly recommend the startup weekend experience for anyone who is seriously committed to working on or with software teams–the pressure of an insane deadline like that compels you to strip everything down to the purest, simplest form: communication, decision making, work flow, product features, everything, and conversely, it also leads one to discover the enormity of one's own personal resources. We were like those people who, in a crisis, lift a car off of a person. Heady, empowering stuff.

This weekend was Startup Weekend World, with 50 cities participating. There will be another soon enough. Hope to see you there!

Share it!

Long Live Lucky Oliver


On Wednesday, I’m doing a presentation on doing presentations. One of the little gems that I was looking forward to passing on was Lucky Oliver. It has been my favorite source for images for presentations and the web. The quality and variety of the images has been consistently great, and the prices were more than affordable. Today I discovered that Lucky Oliver will be closing down on May 15th. I’m sad to be losing this source for great photos, and sad to see the business fail. Best of luck to Bryan, and everyone else at Lucky Oliver.

Now where am I going to get my images? Any suggestions?



Share it!

SDForum SEM Sig

I spent the evening at the SDForum Software Engineering Management Special Interest Group (SEM Sig) meeting. The room was filled with engineering managers of almost every type and experience level. The presenter tonight was Narinder Sandhu, who worked at HP and Intuit before founding T-Rex Global. He managed to get everyone in the room to do a basic skills-assessment and career action plan, as part of his presentation comparing large companies to small startups.

After the formal presentation, the informal discussions were amazing. I talked with people about things as diverse as: finance, feedback, agile development, a mathematical model for organizational structures, and C vs. Lisp vs. Verilog! Oh yes, I’ll be back.

Share it!

Speaking of techdirt…

I was recently invited by techdirt’s Mike Masnick to be a part of the Techdirt Insight Community. The idea is really interesting:

The Techdirt Insight Community is a service that lets a company engage a dynamic and diverse group of experts who provide analysis and insight tailored to meet your specific needs quickly and cost effectively. Our qualified community of expert bloggers tackles your issues through an interactive online conversation and quickly provides you with the answers you need to drive your business forward.

I’m looking forward to it!

Share it!