This touched a nerve. It caused a flashback of the Teen Talk Barbie “Math class is tough” incident in 1992 and the aftermath.

What has changed in 21 years? There has been some progress…

• Mattel came out with a Pediatrician Barbie.
• A few women rose to global prominence in the high tech world: Carly Fiorina, Meg Whitmann, Sheryl Sandberg, Marissa Mayer, many more.
• Many successful companies are co-founded and/or led by women. A random East Coast sampling includes CyPhy Works (Helen Greiner, ex iRobot), Data Gravity (Paula Long, ex EqualLogic), Communispace (Diane Hessan), care.com (Sheila Marcelo), OneForty – sold to Hubspot (Laura Fitton), and so on.

…But much work remains.

• While the aggregate gender ratio has more or less evened out at MIT, historically male dominated disciplines remain male dominated. According to this slightly stale Quora answer, in 2011 Mechanical Engineering (Course 2) was 36.8% female and EECS (Course 6) was 31.7% female.
• In recruiting ME/EE/CS engineers to join our team over the past two years, we noticed the incoming funnel was nowhere near 30-40% female.
• When asked to write an essay debunking a stereotype of her choice, my 11 year old immediately chose “Girls can’t do math” as her topic.
• Oh, of course, there are always moments like this to highlight the “different availability of aptitude” issue (also known as the Larry Summers foot-in-mouth issue).

21 years and not much to show for it. Our school systems are not effective in nipping stereotypes in the bud. Most STEM fields remain male dominated.

What are YOU willing to do to help?

Some practical mitigations are already being done in the startup space. For example, prominent people like Brad Feld have been using their platform to raise awareness. Angel investors like Golden Seeds specialize in investing in women entrepreneurs. There have been versions of the startup weekend catering to women entrepreneurs as well.

Another mitigation is to work on prevention, starting with the younger grades in the school system. Adults (male or female) can proactively mentor young girls who trust them to pursue their interest in things like math clubs, science clubs and robotics leagues. I recently moderated a panel discussion on STEM careers for MIT female undergraduates. I asked each young woman to recount how they ended up at MIT. Everyone had a personal story involving a mentor in a STEM field, who actively coached them to explore these interests. Things like the LEGO league cater to children in Grades 4 through 8, and is a great first experience for girls to try systems level engineering. There are plenty of resources for teaching girls (and boys) to program as well.

A third mitigation is a call to action for female scientists, engineers and technologists to embrace opportunities to speak to school groups about their work. My children’s school invites a geologist to come talk to them about rocks and crystals once a year. That brings interest to an area of expertise few children have access to. Even better, the expert is a female role model. If you are a female in STEM, consider what you can do to share your enthusiasm about your work with school groups. Seeing is believing.

The last word of wisdom comes from this Boston Globe article about shattering the glass ceiling. Between this, and Sheryl Sandberg’s much anticipated book about leaning in, women should take note: believe in yourself and achieve great things, and you will help inspire the next generation.

I hope that with these and other measures, in another 21 years, no one will be writing yet another blog article lamenting the fact that nothing much has changed.

Interacting with them mirrored a lot of interacting with adults in the workplace. Here are some lessons I took away from this experience.

Set clear expectations and keep reinforcing the message
At the science camp, all meals are served in the dining hall. There were specific rules about how the food will be served from the kitchen, where to refill the pitchers of milk, juice and water, what to do with the leftover food, and how to clean up afterwards.

The rules were read 3 times a day for 4 contiguous days. The kids groaned the second or third time they heard it, but they needed the repetitions. This is because there were a vast number of rules to cover the entire meal, and some of them are non-obvious and changes slightly from meal to meal, like how to dispose of food waste (into the pig food bucket – but not if there’s bacon or chicken bones), compostables, recyclables, and trash. No one liked having the rules read to them at the beginning of each meal but that was both necessary and very effective in keeping law and order in the dining hall with 120 hungry kids.

Lesson learned: clarity equals effectiveness – people do much better when it is absolutely clear what is expected of them, and they are reminded of the expectations at the right times.

Give them space to prove how capable they are
At our house the adults do most of the serving and cleaning, mainly because we are lazy – we can do it faster and we don’t want the food to be spilled or otherwise go to waste. At the camp, children are assigned rotating jobs including getting 12 kids’ worth of food on a platter from the kitchen to the table. That is actually a very heavy platter. We probably wouldn’t have chanced it at home but the kids did great – when the platters were heavy they spontaneously asked for help and not one platter was spilled en route to the table.

Lesson learned: let go, ask for and expect more and they will rise to the occasion.

Spilling some milk isn’t the end of the world

However capable they are, they are 10 or 11 year olds after all and they do knock things over at the table from time to time. One time an entire pitcher of milk was spilled on the table. I started to get up to help but the entire table of kids had already self-mobilized and some went to get kitchen towels while others did what they could quickly with the paper napkins on the table. In 5 minutes the table was cleaned up and we were sitting down again to finish our meal. I was never so impressed in my life.

Lesson learned: Mistakes are ok particularly if you don’t go in to rescue them if something does go wrong. They will fix it by themselves if the fix is within their capabilities.

Improve effort and performance with positive reinforcement

At the end of each meal the camp teachers award a pitcher of fake flowers to the table that did the best job at cleaning up. This resulted in tremendous teamwork. The winning tables for the first several meals were clean enough not to require “touch-up” cleaning afterwards.

There was one table, however, that really struggled with the concept of “clean”. During the first few meals, it really wasn’t apparent they had cleaned up after they thought they were done. The teachers didn’t say anything, but simply kept awarding the flowers to other tables. This table really wanted to win once, so they worked hard to improve things. On the last day they finally won, “because they showed the most improvement from the first day to the last”. Their table wasn’t the cleanest, but it was vastly better than before, and they were the happiest kids that day. The promise of the award proved much more effective than any constructive criticism the teachers could have given.

Lesson learned: Positive reinforcement, when properly deployed, can effect change with or without constructive criticism.

People can achieve astonishing things if they buy into a goal

I was a parent chaperone in a cabin full of girls who are widely known to be fixated about hair. Each day was a challenge because it was hard to get them mobilized quickly enough to be at the meeting place by 7:45am to go to breakfast on time, since it took so long to fix up everybody’s hair.

One of these days, a teacher told everyone there was going to be an early morning hike – we were to meet at 6:30am and hike up a small hill to see the sun come up. We all thought our cabin was going to pass on this challenge. Instead the entire cabin huddled and decided as a group to go on this hike. They asked us to wake them up at 6am, and miraculously, we had 13 (!!) girls ready and present at the meeting place in 30 minutes when every previous morning was a big struggle just getting them to take turns brushing their teeth. We all went up the hill and were rewarded with the most incredible vista of the sun coming up over a far away valley, with mist starting to clear off in the valley and foliage of every color surrounding all of us.

Lesson learned: If the team buys into a goal and adopts it as their own, they will go to extraordinary lengths to support it – but it has to be their own idea.

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.

I happened upon an Inc. magazine article yesterday, where Marissa Mayer (CEO of Yahoo) is reported to believe that burnout is a myth.

There are some interesting points made in this article, some of which I do agree with and some of which are head scratchers:

• Burnout has nothing to do with long hours
• Lots of people work long hours continuously for decades
• Burnout is more about resentment when work takes people away from things they truly care about – e.g. children
• To avoid burnout ensure people make time for the things they do care about

The bit about resentment is certainly true. But I disagree with the part about burnout having nothing to do with long hours. Ms. Mayer has superhuman stamina. Most people probably can’t survive a 130h work week on a sustained basis. While I am in awe of her dedication, I rather think this datapoint is six sigmas out of the norm.

The fact remains that if someone is working that much, they don’t have time left to take good care of themselves. They aren’t exercising or eating properly or spending quality time with their family. This is fine when you are 25 and your body can take any amount of abuse and show no bad effects. For those of us who haven’t been 25 for a while… not so much. People get physically sick after a while, either with garden variety colds or with stress related illnesses.

The other thing I find, which seems counter-intuitive, is that when people have things other than work to think about, they think better and perform more effectively at work. This is certainly true for me: I volunteer at MIT and work with students to mentor them on entrepreneurship, and I always find that talking to students helps me refresh my perspective on my work and helps me arrive at new insights that I might not have arrived at without some external stimulation. If I can spend some time kayaking or riding my bike over the weekend, I come back to work balanced and refreshed and able to think more clearly on strategic matters than if I worked both days over the weekend.

So, in short, I think the article is fine and provocative, but I try to be vigilant and take what steps I can to prevent burnout in my team. I try to make people take comp time right after a big crunch, and to the extent possible, I try to regulate the big crunches so they don’t come too close together. It’d be nice if we can plan our work better to head off these big crunches altogether… but that’s a topic for another day.

Priceless! (Many thanks to the wise soul who introduced me to this – you know who you are!)

So far the thing that interests me the most is the connected cars phenomenon. Mercedes-Benz, Audi and Ford each have their own proprietary platform that connects to the internet and allows you to get information from the internet and/or use your mobile phone to check the status of your car. This seems to be an idea whose time has finally come. Here is a video showing the Mercedes-Benz system. (As a former Audi owner I would have loved to show the Audi system instead… but this video is more digestible.)

This is especially interesting to me because some 15 years ago, while I was with a product design consultancy, I was part of a team that worked on an “infotainment car” concept with a cutting edge automobile company that shall remain nameless. We did an ethnography study where we shadowed research subjects for an 8-hour day as they drove around, going about their normal business with us and our videotaping equipment in tow.

We crunched the data, and came up with what we thought people would want to do in the car: get location based information such as nearby restaurants, get turn-by-turn navigation help, get entertainment such as music and video in the car, and get help and support if they get into trouble. We understood that the user’s eyes have to be on the windshield and we thought of wacky ideas like a heads-up display (HUD) superimposed on the windshield, so that critical information may be presented to the driver without requiring them to take their eyes off the road. We called this the “infotainment car” concept.

Considering this was mid 1997, US cellular networks were in the dark ages (GSM/GPRS was not even approved as a standard), and the most advanced connected car technology on the market at the time was General Motors’ OnStar system (equipped with a GPS, an analog cellular uplink and people answering calls), the infotainment car concept was truly a glimpse into the future.

We eventually visited the automotive company’s advanced research lab and saw such a concept car with all the requisite technology. This concept car would have worked from a technology standpoint. Its only problem was that the technology was very expensive and far from mature, and the content and infrastructure was sparse, and in some cases, non-existent. The ideas were wonderful and in hindsight, more than prescient, but the content and technology limitations made it impossible to realize the full richness of the user experience. The concept car stayed in the lab for another 10+ years.

Fast forward to today, and look how far the technology has come. The cellular uplink is now smoking fast – witness the 4G LTE radio integrated into the Audi. This makes it possible to have a really great data download and media streaming experience. Location based information is accurate and plentiful. Many people (myself included) keep large amounts of personal data in the cloud, making it ever more possible to have an excellently consistent connected experience anytime, anywhere. Advanced display technologies are starting to become a reality. Audi is even talking about a heads-up display.

Here is proof that an idea alone isn’t enough to make a successful product or business. Execution alone isn’t, either (the automotive company knew how to make such a car, albeit at a crazy price point). The right external conditions are the third requirement.

I have another case study that supports this observation. Another company I worked with that shall also remain nameless had thought of the exact same core idea as the MakerBot Replicator. Here is a video from the company explaining this incredible 3D desktop printer.

That idea came up well over 10 years ago and remained unactionable until recently, when relatively more cost effective 3D printing technology, better options for the substrate, as well as 3D digital content creation technology caught up with each other.

As a product person, one must stay on top of technology trends and be alert and aware when the conditions arrive that makes a brilliant but previously impractical idea come into its own. Being in the right place and in the right time is a pre-requisite to success.

At the time, I thought, this is all very interesting, but how would anyone be able to keep 30-40 minutes worth of content in his/her head without a slide deck as a framework? I filed the idea away in the back of my head and continued using PowerPoints in my all-hands team meetings.

Some time mid-year, my team and I realized that our team meetings were falling flat. So flat, indeed, that not only were people bored and disengaged, people in the front row were falling asleep on me. The Q&A part at the end was extra awkward, since no one ever had any questions and everybody was always in a hurry to get it over with so they could get out of there.

It certainly didn’t help that we were holding our meetings in a funky space. We are a startup in a relatively small space, and the largest conference room doesn’t comfortably hold the entire team. So we used to hold our meetings in an open area with very high ceilings. The acoustics was appalling – no one could hear anyone else. Once, in desperation, we tried using a microphone. All we achieved was make the whole experience even more surreal. (A microphone in a team meeting at a startup? Seriously?)

Since what we’ve been doing left much to be desired, we decided to try something new as an experiment:

• We moved the meeting to the largest conference room. We pushed the tables out of the way and liberated chairs from another conference room to create extra seating. Then we packed everybody in. It was tight but we were able to fit everybody.
• We banned PowerPoint presentations. Our functional leaders took turns providing a verbal update, with physical props where appropriate.

We had our first team meeting of the year with these changes. What a difference these changes made! Despite the overcrowding, the team was relaxed and engaged. Everybody paid attention to the status updates. There was a lively discussion at the end about a variety of topics of interest. This was the most interactive all-hands team meeting I’ve been in for a long time. I was blown away with the before-and-after comparison.

It’s amazing how these very simple changes completely changed the dynamics of the meeting and the level of engagement of the participants. Being in an actual conference room somehow helped people feel that they were IN the meeting instead of hovering around the perimeter of the meeting. Just that fact seemed to have drawn people into the content of the meeting instead of sending them off for a nap. Being able to hear people speak definitely helped – and this was particularly apparent during the Q&A when many team members spoke up. And most important of all, not having PowerPoint slides forced people to work on clarifying their message so it is concise and easy to digest and remember – something we often forget to do when we have a slide deck to fall back on. We are most definitely keeping these changes for our next all hands team meeting.

I’ve worked with development teams who were “too busy to generate design documentation”. They say: planning is guessing. They say: a design is useless unless it can be represented in code, therefore you ought to start in code. Many of them then start writing the GUI code one component at a time without having developed an information architecture that provides context to each component.

I say to these friends of mine: action without planning in this case is not so smart if you care about the quality of the outcome. A great user experience comes from a holistic view of the application and an information architecture that accommodates not only the UI needs of components of the application, but the cohesiveness of the user experience as a whole. This is up front work that takes time and effort, but it is absolutely worth it. It saves you from having to do gut rehabs to your GUI to accommodate new features and use cases you haven’t properly anticipated before.

One way to capture the output of this design process is with flow charts and wireframes. A high level flow chart for a web app (or any software application for that matter) explains the functionality of the application and how you get to each part of the application at a glance.

I’m going to use the web site of the Trust Center for MIT Entrepreneurship as an example. Since websites change all the time, here is a screenshot of the home page of this site as of January 2012, featuring my good friend Bill Aulet (the current Managing Director of the Trust Center).

Somewhere during the design process of this site, a project manager had decided on the content that would be presented to the users. An information architect would have worked closely with the project manager to develop a top level site map, easily depicted in the form of a flow chart. This flow chart shows how major content is organized in different pages, and how a user might get from either the home page or a landing page to their content of choice.

Once this high level view exists, the designer would have come up with a wireframe of each key page in the app. Now what is a wireframe in this context? The Wiki has an excellent explanation:

A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together. The wireframe usually lacks typographic style, color, or graphics, since the main focus lies in functionality, behavior, and priority of content. In other words, it focuses on “what a screen does, not what it looks like.” Wireframes can be pencil drawings or sketches on a whiteboard, or produced by means of a broad array of free or commercial software applications.

Thus, we are NOT talking about wireframes in CAD-speak. We are talking about a fairly specific form of design output.

Continuing the example above, the home page wireframe for the Trust Center website would likely have looked something like this.

As you can see, a wireframe is not a graphical design. It is instead a concept for a page layout that contemplates the information to be presented to the user (e.g. title, subtitle) and the actions the user need to be able to take (e.g. subscribe via RSS or email) and arranges things in such a way that a user can accomplish most of the mainstream workflows they came to your site to achieve (e.g. read the latest post).

The wireframe is intentionally very stylized in presentation in order not to confuse the reader with any graphical treatments that may cause him or her to latch on to something irrelevant (e.g. the quality or choice of the banner image), instead of focusing on what is the most important at this stage of development (e.g. the user workflow and use case scenarios). It communicates key technical requirements to both the project manager and the developer and helps them negotiate and plan the development work that implements this design.

Now if someone was to plan out a website in its entirety and inventory all of the screens, they would come up with way too many screens to design in this manner. So how many wireframes are really needed? I believe one should at least make as many wireframes as there are unique templates.

A template is a webpage layout that specifies what content goes where. There can be many pages with different content that uses the same template. Going back to the Trust Center website, you can see that several subpages all have the same layout, but different content within each block of information. For instance, if you were to browse the Trust Center site, you will quickly discover that with the exception of the home page, all the pages accessed with the top navigation bar (e.g. Activities > Curriculum, or News) share the same 2-column template.

Since they are all the same, they can be depicted using the same wireframe.

Hopefully this post has helped demystify the front end of web development. The organization of information into different pages is an information architecture exercise; the wireframe design for each unique template starts to pull in interactive design. Once that’s done, graphical design comes next – that will be the topic of another post.

While this wasn’t a particularly useful tool, it’s pretty and fun. On a whim I did it again today after 8 months.

It’s still fairly useless but it’s fun to see how my network has grown

This is the sixth post in my Product Planning Series.

The mere word “requirements” can make a lot of startup people wince. It conjures up the bad old days where folks spend months developing an MRD, PRD and a Functional Specification. It brings up images of Stage-Gate and classic Waterfall processes.

There are situations where big long planning documents make sense.   For example, if you are developing a medical device that needs to go through the 5(10)k process, you really have very little choice.  You have to go by the medical devices handbook which pretty much stipulates that you need to write all those documents and place them under a document control process.

However, in a startup situation, where you really don’t know if your problem, solution, and business model will jive with customers and users, overinvesting in planning documents just leads to lost time and productivity.  It also sends the wrong message to the team: instead of being open minded and work closely with customers to define the product and the business model, you are making up too much of it in the office. By the time the big MRD is written the world has already changed and the requirements could be obsolete.

I am against over-investing in requirements documents. However I am even more against not writing anything down and relying on tribal knowledge to implement a solution. That works if there are, like, 2 people in a startup. When you have more than 3 or 4 people working on the same thing, communications becomes very important. Working in a fast paced startup where new data comes in constantly is not an excuse to punt on basic common sense.  Good team communications practice begats good project execution, which will increase the probability that your product will do what you want it to do in the marketplace.  By the way, this goes for hardware AND software.  Even an agile process needs a holistic view of the end goal.

Here are some requirements do’s and don’ts in a startup setting.

DO

• Write SOMETHING down
• Get buy-in from ALL STAKEHOLDERS.
• Be practical and specific. Leave it loose at your own risk.
• Build a top level project plan that identifies key tasks, milestones and interdependencies
• Develop a lightweight 2 year roadmap

• Start building anything without buy-in
• Write a 100 Page MRD
• Overspecify details on each feature in classic Waterfall fashion
• Build a 5 year product roadmap with a great deal of detail

• Clear description of the market problem that is being solved
• “Elevator pitch” of the solution (preferably with images)
• Description / analysis of first target segment
• Buyer and User Personas
• Detailed storyboards on top 1-3 typical workflows
• Specific examples for details encountered in each workflow
• Considerations for human factors / human cognition
• Top level design directions to be followed by product design team
• Lightweight functional description of minimum viable product (MVP)
• Quick and dirty 2 year product roadmap
• Any external business drivers (e.g. trade shows, funding runway, etc.)