»
S
I
D
E
B
A
R
«
Lean startup experiment, phase 2: building the MVP
Aug 24th, 2011 by Joca

My lean startup experiment is an experiment I’m running to see if it is possible to launch a successful product (product = customer facing software system) without spending too much money and in a short period of time.

Actually the name startup is a bit misleading because this process could and should be use not only by startups but by companies of any size. This process integrates quite well with Agile Software Development and with Continuous Delivery. For this reason, instead of lean startup, I prefer to call it agile product discovery.

Phase 1: idea funnel

I already mentioned about my lean startup validation experiment in a previous post. In the first phase I had 5 new product ideas and used unbounce to build a simple page describing the service and asking people to provide their email address if they wanted to be notified when the service. Then I setup a Google AdWords campaign for each product idea in order to generate traffic for the product pages.

Cost so far, $300 for each product test, total $1500.

The product with most interest was a calories log system where the user informs the food she ate during the day and the system calculates the total amount of calories, also informing how many of those calories were red (we should eat only 10% of red calories per day), yellow (up to 35% is ok) and green (at least 65%).

Phase 2: MVP – Minimal Viable Product

Ok, now that I have a product idea with potential demand, I should build an MVP (Minimal Viable Product) to better understand this demand. In order to do that, I need a logo, a visual design and a system.

For the logo, I decided to use a Brazilian service named We.Do.Logo, a crowd sourcing system where you describe why you need a logo and many designers present you with options. You get to interact with them and eventually you pick one. The name of the system is ContaCal. Conta means count in Portuguese. The winning logo is:

ContaCal logo

ContaCal logo

I paid $310 for the logo.

For the system, I decided to use a service called Startup DEV. With an agile style planning meeting plus 48 hours of coding, they deliver the MVP. I hired them, send them my wireframe:

I also selected a WordPress template from themeforest to be the guide for design. The cost of the template was $35 and the Startup DEV service cost $3K.

The result was great. The Startup DEV team did a great job and now I have an MVP to test. I’m still finishing the web site and will probably launch the service o during the next weekend. By launch I mean sending an email to all the people that showed interest during phase 1 and resuming the Google AdWords campaign.

But meanwhile I want to invite you to use ContaCal. The system was made in Portuguese and I still don’t have plans for an English version. Next steps will depend on demand. 🙂

To use ContaCal, please visit http://app.contacal.com.br.

Total cost and time so far: $5,025 – 3 weeks

  • Phase 1 (idea funnel): $1,600 – 2 weeks
    • 5 product ideas pages in unbounce: $50
    • 5 Google AdWords campaign: $1500
    • 5 Domain registration: $50
  • Phase 2 (MVP): $3,425 – 1 week
    • crowd sourced logo: $310
    • wordpress template: $35
    • wordpress template adjustments: $80
    • startup dev MVP development: $3000

Stay tuned for the next steps

  • website launch
  • online campaign (Google, Facebook, Orkut, etc.)
  • real users feedback!
5 people like this post.

Agile Product Discovery
Aug 21st, 2011 by Joca

I recently posted and twitted about my lean startup experiments.

The word startup in lean startup may be misleading because startup gives the idea of a new company creation. However, the concept on lean startup fits very well within established companies, no matter its size. I believe that instead of using the startup word, I’d rather name it as Agile Product Discovery, an iterative process of discovery of a problem and its best solution that can be turned into a product.

I’m reading now The Entrepreneur’s Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany:

The book’s cover is a cheat sheet by itself:

Here’s an excerpt of the book to give you motivation to read it all:

First, draw a map of your ecosystem.

  • The entities involved. Draw a box or a circle representing each entity in your ecosystem. Entities include users, customers, channel partners, technical partners, strategic partners, advertisers, your customers’ customers, etc. Include all entities that either provide value to you or receive value from your product. Value can be derived from money or the use of a product. Value can be direct (what a user receives from using a product) or indirect (money an advertiser gets from product user eventually).
  • Flow of currency. Draw lines or otherwise show your assumptions regarding the flow of currency. Who pays whom?
  • Product Distribution. Show your assumptions regarding how the product moves through channel(s) to reach end users.

Questions to consider:

  • Are you relying on third party technology that requires a formal partnership?
  • Are you relying on channel partners that will help you bring the product to end-users?
  • If you have a “free” business model and are looking to scale users, who will you eventually earn money from?
  • Are you partnering with a manufacturing firm?
  • Will you sell data or leads to third parties?
  • Does your product benefit your customers’ customers?

Second, define the value proposition for each player.
Each entity is only a member of the “ecosystem” if it will receive benefits by participating. For each member of the ecosystem, what benefit do they gain and what are they willing to trade in exchange? These value proposition statements will evolve into your core C-P-S (Customer-Problem-Solution) hypotheses that you test during Customer Discovery. For now, however, provide a concise description of the value you presume they will receive.

Examples:

  • Users will be entertained
  • Advertisers get the attention of thousands of users
  • Buying influencer is happy to choose “green technology”
  • Customer’s customer gets highly qualified leads
  • Channel able to sell services on top of product
  • Customer will save money, mitigate risk, or increase market share

Third, posit a final MVP
As defined above, an MVP is “a product with the fewest number of features needed to achieve a specific objective, for which users are willing to ‘pay’ in some form of a scarce resource.” The reason the definition is somewhat obtuse is that we wish to differentiate between a “final” MVP and one or more intermediate MVPs. Final MVPs ostensibly test the business model. Intermediate MVPs test high risk components of the business model.

To develop assumptions regarding your final MVP, think of what you need to provide to each entity with whom you have a direct relationship in order to achieve the value you identified above. What are the basic features of the product each user requires to get the ecosystem functioning? What does each entity pay – whether money, attention, resources or some other currency? Describing what your final MVP looks like establishes an end point to the Customer Discovery process.

  • Currency = what the user/buyer “pays” for using the MVP
  • MVP Metric = what you are measuring to determine viability
  • Value Determinants = what the user/buyer requires (minimally) in order to spend their currency, such as features

Fourth, where’s the risk?
The goal for laying out a path for your Customer Development efforts is to prioritize and test your gating factors. If you validate key assumptions, you have proven critically important aspects of your business model. If you hit unexpected roadblocks and points of failure, then you have increased your odds of success by catching these issues early.

Think of critical near-term risks. Does your technology represent a significant risk? In other words, can you build what you believe the market needs? If your technology is difficult or costly to produce, what market-testable milestones can you build that would result in sufficient evidence to induce you to pivot or move forward? A proof of concept? A prototype? A demo?

If your risks are predominately marketing ones, what minimum set of features will result in paying customers? Or: What minimum set of features will result in a minimum of X number of users?

Time and money risks may affect intermediate MVP decisions. If your MVP will require $XM to build, but you only have $X/1000M, an intermediate MVP might be the answer to “what must I prove in order to acquire additional funding?”

Think of dependencies. If your final MVP requires that X happen, then can you build an intermediate MVP around X? What does X depend on? If possible, go to the root of the dependencies.

Fifth, create your Value Path
Your value path is the journey of Customer Discovery that takes you from where you are today to your proposed final MVP and includes both intermediate MVPs and core assumptions to be tested. From the risk table you created, map out the set of core assumptions you need to test for each identified gating factor. For each intermediate MVP, you will likely have a set of assumptions to test through direct customer interaction, in addition to a version of the product to build and test through usage.

1 person likes this post.

The difference between a product and a project
Aug 15th, 2011 by Joca

Here’s a brief definition of a project:

A project is an endeavor with a clear definition of what needs to be delivered and the date when it needs to be delivered.

At first sight it may seem that a product is a project, but it is not!

A product is not a project because:

  • There’s no clear definition of what needs to be delivered. We saw in a previous post that a product in the software development industry is any customer facing system. Since customer needs evolve over time and new technologies are made available, the customer expects that the software she uses evolves as well, hence there’s no clear definition of what needs to be delivered. There’s no use to have a one year planning of all features to be delivered in a certain sequence if requirements may change every month or even every week. A product development process needs to be adaptable to this change in customer needs.
  • There’s no clear definition of the the date when it needs to be delivered. As customer expects that the software evolves in alignment with her needs, she doesn’t want a new version one year from now. She expects new features every month or even every week. For this reason, a product can not suffer the burden of the project management process. The product development process must be much leaner than the traditional project management process, because delivering new functionalities to a product is always the same project for each new feature: discovery, design, implementation, test, deploy. A project is used to manage occasional endeavors. The product development process is not an occasional endeavor. It’s a continuous process of improvement of the product through the delivery of new features.

A product needs a more adaptable and continuous development process than traditional project management delivers. Agile Software Development, Lean Software Development and Continuous Delivery are process that present these characteristics.

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Source: Wikipedia

Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community.

Source: Wikipedia

Continuous Delivery aims to make software production-ready throughout its lifecycle, so that potentially every good build can be released into production and run effectively. The goal is to “…Minimise the cycle time from idea to delivery, and allow that cycle to be repeated frequently and reliably.”

Source: Wikipedia

Lessons learned

  • The difference between a product and a project is that while a project is used to manage occasional endeavors, it doesn’t fit with the continuous improvement demand of a product.
  • A product requires more adaptable and continuous development process such as Agile Software Development, Lean Software Development and Continuous Delivery.
14 people like this post.

Lean startup experiment, phase 1: the idea funnel
Aug 7th, 2011 by Joca

Four weeks ago I started an experiment. I had 5 ideas of possible startups so I put together a simple page for each idea explaining how the service was supposed to work, how much it would cost and if the visitor has interest, she can inform her email address to receive news of the service. I’m not a web designer, so I needed help to put together a simple page for each startup idea I wanted to test. @dovb recommended a very good service named unbounce:

I defined a name for each startup idea and registered a domain for each one so each startup description page had its own URL.

I used Google AdWords to generate traffic:

I set $15 per day as the limit for each startup campaign. The startup description pages received a total of more than 2500 visits and more than 300 people shoed interest in the services described in these startup description pages. This hole experiment cost me $1500 including AdWords, unbound service and domain registration. $300 per each startup experiment. It could have cost even less since the interest (click through rate and sign up rate) was clear after the second week of the experiment.

Lessons learned

    Next time you have a startup idea, try running a startup validation experiment. It will certainly be cheaper than investing too much time and money in your idea and after launch realizing that there are no customers for your startup.

4 people like this post.

The new rules of marketing and PR
Aug 1st, 2011 by Joca

I’m reading a very interesting book entitled “The new rules of marketing and PR: How to Use News Releases, Blogs, Podcasting, Viral Marketing and Online Media to Reach Buyers Directly“:


I’m still reading it but its central idea is so simple and powerful that I wanted to share it here prior to finishing the book.

What is marketing and PR?

In the book, marketing is defined as the act of telling the world about your product, service, idea, art, belief, etc. to potential customers, volunteers, voters, followers, fans, etc. And public relations (PR) is the act of making the media talk about you and what you want to tell the world.

How marketing and PR are usually done?

Marketing is usually done primarily thorough advertisement in TV, newspaper, magazines and any other available media. PR is usually done sending press releases to journalists expecting to see a note in mainstream media.

How the internet changed marketing and PR?

People want to get more informed prior to any commitment to a purchase or an engagement with a cause or pursuing a new hobby or… People now have access to the internet and can search information. We normally buy or engage with who give us good information. Even journalists don’t wait for new information to come to them, they go after the information on the web the same way potential customers do, searching the web. And the journalism itself changed, since there’s much more than just the mainstream media as possible source of news and opinions.

The new rules of marketing and PR

And here are the new rules of marketing and PR as described in the book:

  • Marketing is more than just advertising.
  • PR is far more than just a mainstream media audience.
  • You are what you publish.
  • People want authenticity, not spin.
  • People want participation, not propaganda.
  • Instead of causing one-way interruption, marketing is about delivering content at just the precise moment your audience needs it.
  • Marketers must shift their thinking from mainstream marketing to the masses to a strategy of reaching vast numbersof underserved audiences via the Web.
  • PR is not about your boss seeing your company on TV. It’s about your buyers seeing your company on the Web.
  • Marketing is not about your agency winning awards. Its about your organization winning businesses.
  • The internet has made public relations public again, after years of almost exclusive focus on media.
  • Companies must drive people into the purchasing process with great online content.
  • Blogs, online video, e-books, news releases, and other forms of online content let organizations communicate directly with buyers in a form they appreciate.
  • On the Web, the lines between marketing and PR have blurred.
3 people like this post.

Try AND instead of OR
Jul 20th, 2011 by Joca

I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:

One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.

It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.

It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:

  • freedom and responsibility
  • cross-functionality and specialization
  • continuous learning and iteration pressure

It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and. 🙂

Lessons learned

Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.

1 person likes this post.

To freemium or not to freemium?
Jul 17th, 2011 by Joca

Some of today big companies offer their services for free (Google, Facebook, Twitter, Linkedin, Slideshare, Youtube, etc.). They generate revenue through ads, having a paid version with more features or offering paid add-ons to users of the free product. This is known as freemium.

Should my product have a free version?

In order to benefit from offering a free version, your product must benefit from having a huge user base because of at least one of the reasons below:

  • your product has many social features (Linkedin, Facebook, Twitter, Skype, etc.)
  • your product needs user generated content (Slideshare, YouTube, Flickr, etc.)
  • your product will attract a user base to whom you’ll be able to show paid ads (Google, Facebook, etc.)
  • your product will attract a user base to whom you’ll be able to sell something in the future (Linkedin, Slideshare, Skype, etc.)

So before going freemium you need to understand why you are offering a free service. Then you need to figure out…

How do I make money to pay the costs of the free product?

After you figured out why you intend to offer to free service, you need to know how to generate some revenue because offering a free product will cost you money. All of the companies cited here had to figure out how to make money from their huge user bases. Here are some ways they used to generate their revenue:

  • you can sell the attention of your users to advertisers (Google, Facebook, Twitter, Youtube, etc.)
  • you can convince part of your user base to buy the paid version (Linkedin, Slideshare, etc.)
  • you can convince part of your user base to buy one-time add-ons (Skype is the only example that comes to my mind with Skype credits)

Tip: If you decide to go freemium, don’t forget that you can only offer a free product if your marginal cost of adding another user to the product user base is as close to zero as possible, otherwise it won’t be a sustainable product and your urge for revenue may kill your freemium product.

Lessons learned

Freemium is a viable business model but before offering a freemium product, you need to figure out:

  • why offering this product as a freemium might make sense
  • how you intend to make money to cover this product costs
  • the marginal cost of adding another user to this product user base must be as close to zero as possible
4 people like this post.

What is Product Management?
Jul 3rd, 2011 by Joca

DDD (Domain Driven Design) has a very powerful concept, so powerful that it is the first concept presented to anyone who is initiated in DDD, Ubiquitous Language:

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

source: http://domaindrivendesign.org/node/132

It’s a way to guarantee a shared understanding of the main terms used in a domain.

I’ll start to write more about Product Management here, so I felt the need to define Product Management prior to writing more about it.

Product

Prior to defining Product Management, let me define product in the software development industry:

Product is any customer facing software system.

A customer facing software system is not necessarily a system which drives revenue through subscription or on-demand use. A system like a newspaper portal can be considered a product. The revenue from such a system probably will come from ads. An internet banking is another example of a customer facing system who would benefit from product management. It doesn’t drive direct revenue but it helps decreasing cost of physical bank offices.

Product Management

And here goes the Product Management definition:

Product Management is accountable and responsible for everything from high-level objectives to the details of the user experience of a customer facing system. It’s the connection between the business strategy and the customer through a software system.

3 people like this post.

Why there are so few women in programming and why this matters
Jun 19th, 2011 by Joca

Sometime ago I was talking to some friends from ThoughtWorks when one of them asked me why there are so few women in the IT industry? Specifically, why there are so few women in programming?

Since I’m an open water swimming aficionado my first reaction – quite naïve reaction by the way – was to attribute to the physical gender differences such as we see in sports. Women don’t compete with men in sports because there are physical differences. A women world record in any swimming event is different from men world record. But my friends replied that there aren’t any known physical differences that can justify why there are so few women in the IT industry. And they pointed out that the right direction for an answer was in the social and cultural realms. So I kept thinking about this topic, did some research and I want to share my findings.

Background

I still don’t know why but my parents decided to put me in a male only school from 6 to 17 years old. My school decided to accept girls when I was 15. In my last year of school I had to choose between exact, bio or human sciences as part of the preparation for entering university. I chose exact science and my classroom of 35 people had only 2 girls. I started to realize that exact science and girls were not best friends. By then I decided to go to engineering school. I heard that there are not so many women in engineering schools and I went to visit some of them. I decided to go to ITA, a male only engineering school. It was a male only school because during their first year at ITA, the undergraduate students are required to attend a military preparation course once a week. This is due to ITA’s strong connection with the Air Force. Some years ago ITA decided to accept women. After graduating at ITA, I worked at 4 internet service provider companies and in all of them women was a minority, specially in the technical teams.

So the lack of women in exact sciences and technology has been part of my entire life, even though I haven’t paid much attention to this until recently.

Why gender diversity matters

First, diversity in general matters since diversity brings new ideas, new opinions and new view points. Differences always bring fantastic opportunities for learning and improvement. Recent research from National Center for Women & Information Technology (NCWIT) shows that diverse talent in the technology industry increases innovation, productivity, and competitiveness:

  • A recent NCWIT study shows that teams comprising women and men produce IT patents that are cited 26–42 percent more often than the norm for similar types of patents.
  • In a study of more than 100 teams at 21 companies, teams with equal numbers of women and men were more likely (than teams of any other composition) to experiment, be creative, share knowledge, and fulfill tasks.
  • Additional studies indicate that, under the right conditions, teams comprising diverse members consistently outperform teams comprising “highest-ability” members.

Anita Borg Institute for Women and Technology provides the business case for gender diversity:

The War for Talent – Remaining Competitive: Reaching out to technical women is crucial to a company’s ability to attract and retain the human capital it needs to succeed, and research shows:

  • The cost of filling the vacancy of a skilled technical employee has been estimated to be as high as 120% of the yearly salary attached to that position.
  • Despite popular beliefs about the impact of offshoring on hi-tech jobs, numbers show that the demand for high-level high-tech jobs such as software engineers has increased since 2000 and that offshoring has not slowed job growth in developed countries.
  • Companies are looking for technology workers with more experience and a broader set of skills such as leadership and interpersonal communication skills. Competition for these employees, combined with the drop of computer science graduates and impending retirement of the baby-boomer generation, has led to fierce recruiting competition among firms; nearly 300 technology executives surveyed identified identifying, hiring, and retaining skilled technical workers as their top concern in 2006.
  • Companies with effective diversity inclusion practices benefit from reduced absenteeism and employee turnover.

Women have the skill set for the new competitive demands of technical work

  • Companies agree that they need more technical leaders with varied skills such as interpersonal skills and business skills. 93% of technical leaders in a survey identified the building of collaborative networks in an organization as a crucial component of leadership. Women have the skills to meet the new demands of technological work both in terms of technical and interpersonal skills.

Women are paramount to User-Driven Innovation

  • Women influence 80% of consumer spending decisions, and yet 90% of technology products and services are designed by men. Including women in the technological design process means more competitive products in the marketplace.
  • The most innovative companies design products through user-driven innovation by integrating lead users in the design process. Women bring new markets and new technological applications to the design process and can market effectively to women, opening up new lines of business. Women of various ethnic backgrounds can furthermore open new international and ethnic markets.

Diversity brings benefits to an organizationís image

  • Companies with a diverse workforce generally benefit from a better image in the marketplace.

Diversity makes for better decision-making at all organizational levels

  • Group diversity leads to better decision outcomes, and this has been shown in a variety of settings,
    occupations, and organizations, and also applies to group task performance and to creativity and innovation. Diversity is beneficial because a variety of opinions, backgrounds, and thinking styles and their integration into the solution are what contribute to better decision outcomes.
  • Research has found a correlation between the presence of women in higher management and financial performance of the organization, as measured to total return to shareholders and return on equity.
  • A recent industry report estimates that by 2012, teams with gender diversity will double their chances of exceeding performance expectations when compared to all male teams.
  • Diversity is especially important and beneficial for problem solving and innovation tasks, such as is the case in technology.

Three weeks ago a read an interesting article on men and women in a Brazilian magazine called “Super Interessante”.

Cover of june's edition of a Brazilian magazine on men and women

Cover of june's edition of a Brazilian magazine on men and women

Some interesting facts from the article:

  • Women earn 75% of men’s salary for the same type of work.
  • 57% of the men negotiate their first salary. Only 7% of women negotiate their first salary.
  • Men prefer jobs with performance bonus and competition.
  • With friends, men talk more than women. However, when they are 1 year and 8 month old, women talk 2 to 3 times more than men.
  • Also, girls are stronger, since child death is 22% bigger for boys.
  • Women are 59% of the people who receives a university degree.
  • In 2010 women are the majority of the American workforce.

What can we do to improve this situation

Last week I watched a very interesting presentation entitled “Where Are All The Women?” by Erin O’Brien (@coolaunterin) via @sarahtarap and @dlbock that shed some light on the topic:

facts:

  • general US workforce: 47% women and 53% men.
  • computer and math occupations 26% women and 74% men. Women share is declining.
  • computer programmers: 22% women and 78% men.
  • open-source programmers: 2% women and 98% men.

possible explanations:

  • stereotyped computer programmer image:
    Computer programmer stereotype

    Computer programmer stereotype

  • a study in the university of washington where they introduced women into a computer science department classroom. If that classroom has images of startrek posters and videogame lying around women were less likely to show an interest in the computer science field. If that same classroom, still labeled as computer science classroom, has nature posters and phone booths lying around women were as likely as men to show an interest in computer science industry.
  • it’s a two way street:
    • women need to work to get into the field despite the stereotype
    • people need to work hard to recruit women

Some advice for those who are trying to attract women to work in their companies:

  • Don’t make your office spaces stereotypical. Fill your spaces with non-stereotypical images.
  • Don’t assume all women like shopping, the color pink, or panda bears. There’s not a stereotypical female programmer.
  • Don’t allow gender-specific job titles: mother, diva, princess, babysitter, etc. Use titles that speak to skill and attributes.
  • Women work one hour less per week, but spend twice as many hours on housework as men.
  • Women are not appealing candidates because of maternity leave, sick kids, school vacations, sick spouse. Hence, be flexible for ALL employees for family time.
  • Networking is essential to further the career and networking normally happens in conferences which involves social aspects and traveling. This can be hard for a woman in an environment dominated by men. Additionally, it is bit harder for women to travel.
  • Women tend to self-select herself out and to sell herself short. Organizations need to more flexible on their search for talent and women need to sell themselves more adequately. When men succeed they justify it with their ability and skill. When women succeed they justify it with luck. When men fail they justify it with bad luck. When women fail they justify it with low ability. Hence don’t reject a woman at the resume-level of selection. Give them the benefit of the doubt. Interview all of them even if her resume is not as good as some men candidates. She’s probably selling herself short.
  • Women receive shorter letters of recommendation and lower job performance ratings. So use objective measures of job performance (e.g., # of widgets). Don’t use reviews to determine pay increases.
  • 82 cents is not equal to a dollar. A woman gets paid 82 cents for every dollar a man gets paid for the exact same programming job.
  • Don’t ask women why there aren’t more women in programming. Read blogs, articles, etc. by women in the field.
  • Don’t ask a woman to speak for ALL women in the field. Ask men to speak to other men about the problem.
  • Don’t assume a woman works in HR. Assume she is a programmer.
  • Don’t point out the only woman in the room. Ask a woman how she got started in programming.
  • Don’t assume a programmer isn’t a “real” programmer. Ask her what her favorite project is / was.
  • Start them early!
  • Be careful with language. Women have a natural aversion to risk. “Let’s hack this” may sound dangerous to a woman while it sounds cool to a man.
  • Get involved with organizations helping women (.e.g., STEM – Women in Science, Technology, Engineering,
    and Mathematics
    .
  • Don’t ask women out that you work with.
  • Finally, inspire someone, guide someone, coach someone, mentor someone!

Checkout the full presentation.

Lessons learned

  • We need to recognize that gender diversity matters both because of its social aspect – equal opportunity to all people – and its business aspect – diversity impacts positively the bottom line.
  • After recognizing that gender diversity matters, we need to embrace the difference and work hard to improve this situation. Some suggestions on how to improve this situation can be seen in Erin O’Brien’s (@coolaunterin) presentation “Where Are All The Women?“. These suggestions were summarized above.
9 people like this post.

Collaboration lessons from the marshmallow challenge
Jun 14th, 2011 by Joca

Ingredients:

  • Groups of 4 people
  • 20 sticks of spaghetti
  • one yard of tape
  • one yard of string
  • a marshmallow

Time constrain: 18 minutes

Objective: tallest freestanding structure

Lessons:

  • Who consistently performs worst? Recent business school graduates
  • Who consistently performs well? Recent kindergarten school graduates. Not only the tallest but the most interesting structures.
  • Why kindergarten school graduates do better than business school graduates? First, none of the kids spent any time trying to be CEO of “Spaghetti Inc.”. Business students are trained to find the single right solution. Kindergarteners build prototypes several times, get instant feedback of what work and what doesn’t and refine.
  • The very best group? Architects and engineers, thankfully!
  • CEOs with an executive admin perform significantly better than just CEOs. Why? Because they have special skills of facilitation. They manage the process.
  • Specialized Skills + Facilitation Skills = Success!
  • Incentives + Low Skills = no success.
  • Incentives + High Skill = Success!
  • Every project has its own marshmallow.
  • Shared Experience + Common Language + Prototyping & Facilitation
  • Sometimes a little prototype is all it takes to transform an Oh-Oh moment into a Ta-Da moment!
  • 1 person likes this post.

    »  Substance: WordPress   »  Style: Ahren Ahimsa