Archive for the 'leadership' Category

“What is your leadership style?”

Seoul Summer Orchestra Concert Street Traffic

Recently someone asked me: “Elaine, what is your leadership style?”  My response: “which one of the 100 frameworks out there are you referring to?”

People studying leadership appear to be irresistibly drawn to classifying humanity into categories.  Following are a few leadership style frameworks that I have seen in recent years.

  • Here is a list of 4 leadership styles from Inc back in 2012. The four styles are: directive, participative, laissez-faire, adaptive.
  • Here is a list of 5 leadership styles from USA Today in 2013. The styles include: the sports coach, the driver-director, the mentor, the country clubber, the eclectic.
  • Here is a list of 6 leadership styles from Wall Street Journal, originally put forward by Daniel Goleman in his book “Primal Leadership“.  Also cross referenced by Fast Company. The styles include: pacesetting, authoritative, affiliative, coaching, coercive, democratic.
  • Here is a list of 8 archetypes from Inc., by Manfred F.R. Kets de Vries, the author of “The Hedgehog Effect: The Secrets of Building High Performance Teams”.  The archetypes include: The strategist, the change-catalyst, the transactor, the builder, the innovator, the processor, the coach, the communicator.
  • Here is a list of 9 leadership styles from an executive coaching consultancy, based on the enneagram personality typing system.
  • Here is a list of 10 leadership styles from the Under30ceos.com website. I am not sure what it is based on.

While these frameworks can help people better understand themselves, they can also end up confusing people.  First of all, they oversimplify.  People are complex, and few people fit perfectly into any one style.  Secondly, there are so many frameworks and they don’t all agree with each other. Which one should one read?  Lastly, how many people read one of these articles, see themselves in one of the styles, start justifying their actions, and stop growing as a leader?

To be fair, many of the articles referenced above do mention that good leaders need to adapt to different situations.  But I wonder how many people come away with that insight, after being drawn to an article with a title like this:  “Leadership: 8 Archetypes Explained”.

Leadership is holistic and multifaceted.   No one can stick to any one style and expect to succeed.  Of course we all have our preferred styles of interaction, but different situations will warrant different styles.  For instance, if you find yourself heading up a team with a clearly defined set of objectives and a very aggressive deadline, and you have experience and insight that the team lacks, a directive style would be most effective.  If you have a strong vision about a problem you want to solve, but don’t quite know how to bring it to fruition, you would need to refrain from micromanagement, and learn to give your team the time and space to come up with ways to implement your vision.  If you are implementing a cross functional initiative that needs buy in from many constituencies, then a collaborative and inclusive style would be appropriate.  If you are trying to build bench strength and develop a scalable organization in a time of rapid growth, a coaching style would make sense.

To be an effective leader, you need to be able to do all of these things and more, whether or not you are innately comfortable with adopting these leadership styles.  It’s not easy at all for someone who is a natural at a command-control style to adopt a nurturing or coaching style.  It is equally jarring for a naturally collaborative leader to have to adopt a directive style.  Pushing yourself beyond your boundaries is uncomfortable.  However, challenging yourself to grow and mature will benefit yourself, your team and your organization as a whole.

If you come across one of these frameworks, by all means use it to help gain insights into how you think and work.  At the same time, do consider using the entire list as a learning curriculum.  A leader with a broad range of styles can achieve far more than someone who can only exercise a small range of leadership styles.

What is innovation?

A few months ago, I was interviewed by a group of entrepreneurs from Mexico about my thoughts on innovation.  Here are some key discussion points that came up in our conversation.

Image

What is innovation?

When people use the word “innovation”, most of the time they are thinking about scientific or technological innovation.  To me, however, innovation simply means coming up with new ideas on how to solve problems, and then successfully implementing these ideas into viable solutions, and it applies to every discipline.

Coming up with a non-invasive way to test a diabetic patient’s blood glucose level is innovation. Coming up with novel ways to incentivize a sales channel to double their product sell through rate is innovation.  Coming up with visualization tools for budget-versus-actual analyses to help a cost center manage its expenses is innovation.

Why is innovation key in a startup?

Innovation is critical for any organization that needs to maintain a competitive edge, but for a startup, it is a matter of survival.  Startups are always pressed for time and resources.  They are constantly looking for  new and non-obvious ways to solve problems and meet objectives quickly.  They are constantly solving new problems never solved before.  Being creative and flexible is key.

How do we come up with a process for innovation?

In my mind, the very nature of innovation is non-linear, whereas processes and frameworks tend to be rigid and structured. In my opinion, innovation and set processes don’t go well together. Rather than creating a documented process, we should focus on creating an environment that encourages risk taking and spontaneous, out-of-the-box thinking, which in turn encourages and nurtures innovation.  We should make it ok for team members to try things that aren’t guaranteed to work.  Also consider building in some intentional slack, so people have the space and breathing room to come up with great ideas during their down time.

How can you tell if your organization is innovating successfully?

It’s one of those “you know it when you see it” things.  An innovative organization simply exudes creative problem solving vibes.  There are also objective signs: more patents being applied for; faster turnaround in responding to market needs and customer requests; loyal and happy customers who trust an organization to solve their problems effectively; these all help to show that the organization is innovating where it matters.

Are there best practices for encouraging innovation in a startup?

One thing I advocate is the “tiger team approach”.  I like to pull a cross functional team together from different departments.  This project team gets  together and works on a well defined problem with great focus until it is resolved.  The diversity within the team ensures that the problem is looked at from multiple perspectives.  Effective collaboration results in effective innovation.

Book Review: “Disciplined Entrepreneurship” by Bill Aulet of MIT

My friend and colleague Bill Aulet (currently Managing Director of the Martin Trust Center for MIT Entrepreneurship and Senior Lecturer at the MIT Sloan School of Management) has just launched his new book, “Disciplined Entrepreneurship – 24 steps to a successful startup“.

disciplinedeship

There are a million books out there teaching various aspects of entrepreneurship, many of them I consider required reading for any aspiring entrepreneurs in today’s startup ecosystem. But I agree with Bill when he says that all these books and materials teach only a part of the whole. First timers need a comprehensive introduction to the whole tamale. Which Bill does fantastically in a nice dose of MIT style firehose.

Bill hammers home the importance of testing your assumptions in the field. Other books do this too, but Bill makes it practical.  The single most fatal mistake an entrepreneur can make is to get so attached to their starting idea that they push forward despite warning signs along the way. A rigorous approach to testing assumptions is a powerful weapon against getting caught up in the focus group of one.

What I particularly like about this book is the approachable way Bill demystified the sales process, explained sales models, and outlined how to quantify and track key metrics like LTV (Life Time Value for a customer) and COCA (Cost of Customer Acquisition) beyond the blunt instrument of a financial statement. The chapters on sales and marketing are particularly valuable to technical founders who haven’t personally seen marketing and sales in action.

Another wonderful thing about the book? It doesn’t discuss product roadmap until Step 24 of 24 – which is exactly apropos. First, you establish your right to exist. Then, you can worry about product roadmap. A product no one buys is not a business. Fixating on future products before the value proposition has been proved on the first offeringis a fool’s errand.

Here are some quotable (tweetable?) quotes that I particularly like:

  • “The single necessary and sufficient condition for a business is a paying customer.” (On why having a product no one buys doesn’t make it a business.)
  • “Focus is the most important skill for an entrepreneur.” (On not boiling the ocean)
  • “If there is already a market research report that contains all the information you need, it is probably too late for your venture.” (On why one must do primary research instead of relying on Google search to learn about the market and customers)
  • “Get started doing, rather than getting stuck in analysis paralysis.” (On not agonizing over whether you have picked the right beachhead. You have incomplete data – just make a call and get going.)
  • “(Entrepreneurs) overestimate the enthusiasm their customers has on their product.” (Touché.)
  • “If the only feedback you get is ‘everything is okay’, then it is likely the customer doesn’t care much about your product and its value to them.” (On anticipating and embracing negative feedback)
  • “You cannot will a market to exist any more than you can change the laws of thermodynamics.” (On the need to be willig to change fundamental assumptions, including the choice of a target market, based on new data)
  • “Free is not a business model.” (Enough said.)
  • “Costs shouldn’t be a factor in deciding price.” (On how cost based pricing almost always leaves money on the table.)
  • “It is always easier to drop the price than to raise the price.” (Duh!)
  • “A sound ratio for the LTV to COCA is 3:1.” (Via David Skok – a good guideline for unit dynamics once a startup has reached product market fit.)
  • “The COCA will almost always start at a very high point because you need to first create the market.” (Something a lot of first timers don’t realize, causing panic, when it is part of the process to develop the business model.)

I very much enjoyed reading this book and the many examples.  If you are a first time entrepreneur who wants to learn what questions to ask, definitely add this book to your collection. It is a dense read, but it will arm you with the vocabulary and concepts to probe deeper in each area. Highly recommended.

“Girls suck at math”

I generally don’t talk much about gender stereotypes in STEM (science, technology, engineering and math). I try not to add to the noise – until I saw this on xkcd.com (courtesy of a TechCrunch article about… well… gender stereotypes.)

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.

“Good, fast, cheap” – all 3?

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

Image

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.

Product Planning Series: Requirements

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

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
DON’T
  • 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
At the end of the day, for a development team to be productive, they really don’t need big long documents to describe everything. They just need a few slides on a few topics.  Here are the topics that I find useful to write down for the team. A lot of this stuff should be available for free, from the business case and who/what/why/when discussions.  Some of it is technical – like a lightweight description of the MVP.
  • 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.)
The most important thing is to do the thinking and research that will support the materials presented in these types of documents. The second most important thing is not to overthink things when you write them down.  Use the minimum possible number of pages to convey the information – don’t overinvest.  That way you will not feel too badly if customer development tells you something new and you have to trash some of these documents and write them over.

The many facets of leadership

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

Like any other manager of a functional group, the product development manager wears many hats.  He or she is a technical lead, a head coach, a Gantt meister, an HR specialist, a product architect, a social chair, a strategist, a tactical guerilla fighter, a human shield against distractions, a cheer leader, a measurer and communicator of team performance (whether good or bad), a translator of corporate strategy to his/her team, and a translator of technical jabberwocky to less technical stakeholders.

He/she must take care of his/her product as well as people.  He/she must work effectively with product management, sales, marketing, manufacturing (for hardware products), finance and operations to ensure the output of the development team plugs into a viable and implementable company plan.

How do you measure the performance of the development manager?  Which aspects are the most important to watch?

There is no right answer to this question because the hat prioritization depends on the organization, the state of the product development process, the personal dynamics inside and outside the development team, and the personality and style of the development manager.

For me, under most circumstances, the success of my team defines my own success.  There are two areas to watch:

  • Team performance: Is the team hitting its milestones on execution and developing a great product effectively and efficiently?
  • Team development: Are we nurturing and empowering team members to grow and prosper in their respective careers?

Team Performance
The greatest compliment anyone can give me and my team is to tell us that we are an execution machine. A team that performs well and executes its initiatives is a team that shines.  

Now how do you create conditions to help your team excel? First and foremost, the right people must be in the right jobs.  There’s no way to get excellent performance out of an organization if people don’t have the right aptitude and training to do the job they are asked to do in the time frame that the job needs to be done.   Performance will also suffer if people are made to do things they don’t like to do for extended periods of time.  

Second, we must clearly define goals and objectives, and then stick to them for long enough so the team has a chance to execute against those goals. To be in a startup is to be in flux. New data and learnings flow in all the time and we do need to be able to stay nimble and pivot rapidly when the data tells us to do so. That said, continuous thrashing is the best way to trash a team’s performance and morale. We must strike a balance between our desire to turn on a dime and our need to stay focused so we can execute against the best available information, creating deliverables that will help us test and learn for the next iteration.

Lastly, we need to succinctly define success in a clear and tangible way, then measure the team’s performance against these success metrics.  What you can measure you can improve.  There is nothing more motivating than being able to celebrate victories when we hit our milestones.  And when we miss, those are learning moments that give us valuable data to help improve our performance the next go-around.

Team Development
The second thing to watch for is whether team members feel happy and supported in their jobs, and whether they are growing and prospering along their chosen career paths.

I take the coaching aspect of a development manager’s responsibility very seriously. To the extent possible, the development organization should provide opportunities for team members to learn new things and stretch their skills in their areas of interest.  

While I believe the primary characteristic of a high caliber development team is its performance, a happy, motivated team in a trusted, supportive work environment that looks out for their interests and takes steps to help them grow can usually get more work done faster and with a better quality of output.

What do you think about all this?  How would you prioritize these hats in your own role?

Product planning series: Staffing for success

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the third post in my Product Planning Series.

I decided to write this post after realizing that the actual activities and functional disciplines involved in building a new product are not necessarily apparent to people new to the game or seasoned professionals who come out of an unrelated functional discipline (e.g. finance).

Disclaimer: while the activities involved are generalizable, the actual staffing suggestions are only appropriate for a small company with a total headcount of 20-50. Companies much smaller or much larger than that will have a very different approach to staffing.

Activities involved in bringing a new product to market
There are several activities involved in bringing a new product to market. These activities need to happen regardless of who actually does the work.

  • Strategic product management – market sizing and analysis, identifying a market problem worth solving, choosing a target market segment, developing a business case, coming up with a pricing model and go-to-market strategy, etc.
  • Technical product management – persona development, requirements gathering, use case development, specifications development, generally advocating for the customer and end user’s needs and wants within the organization
  • Project management – generating a program plan that spans disciplines, with clear task breakdowns, milestones and deliverables, then managing against this plan
  • Technical development – implementing the product according to specifications, whatever form the specifications come in
  • Quality assurance – checking the homework of the implementation to ensure it works as advertised
  • Product marketing management – planning and executing market launch activities for this product to generate awareness
  • Customer support – fielding inquiries from buyers and end users about the product, how to purchase, how to use, and resolving issues as they arise
  • Sales – attracting target customers to try and / or buy the product

Hiring the right leaders to head up the product team
In a one-person startup, that one person will have to wear all of these hats. In reality, that is hardly optimal. Not only would this make for one grossly overworked individual, but I personally don’t know any one person who is fantastic at all of the above activities. Most of the time you will need multiple people to make up a product leadership team. Following are my personal take of who should be on this team. Your mileage may vary.

  • Product Manager – enough said. This person takes care of product strategy, requirements gathering and product definition and is in charge of customer research. He or she is the internal advocate for the customer.
  • Development Manager – this person heads up the technical organization and manages engineers. QA often reports to the Development Manager as well.
  • Product Marketing Manager – this person is frequently not the product manager. PMM is predominantly an outbound function, while PM is an inbound function. The PMM comes up with the right messaging to communicate the benefits of the product and takes care of market launch activities.
  • Sales Manager – this person uses positioning, messaging and other support materials generated by the PM and PMM to convert customers. Customer support often reports to sales as well.
  • Operations Manager – in hardware companies, this person is concerned with manufacturing, operations, inventory management, and supply chain management. In web software companies, this person is concerned wtih server care and feeding, failover policies and the like.

Development team for a consumer SaaS web app
Having put together the leadership team, and hopefully defined the product to an actionable degree, you will need to assemble a team to do the actual development. The talent required on the development team depends 100% on the actual product or service itself.

For the example I’ve been using (i.e. a music education SaaS offering for young children), I would need to hire / assign the following people:

  • Project Manager (PM) (this can be the development manager). This person is the Gantt Meister. (If you don’t know what a Gantt Chart is, you should probably not be the Project Manager yourself.)
  • Information architect (IA). This is the person who has the most impact on user experience (UX) – they worry about how end users achieve their goals and how information is presented to them.
  • Graphic designer. Contrary to what some people think, great information architects often don’t do all of the graphical presentation themselves. One way to think about it is that the IA worries about the cognitive aspect of a workflow, while the graphic designer worries about the esthetic presentation of this workflow. Between the IA and the graphic designer, the look and feel and actual UX of the web app is determined.
  • Client side web developer. This is a developer who is highly adept at manipulating XHTML/CSS and is comfortable with various technologies to implement the designs created by the IA and the graphic designer. They can make any interactive effect shine on the front end. Some of them are strong graphic designers in their own right.
  • Server side engineer / architect. This is a software engineer who chooses the right technical platform to develop on, architects the code, and decides how this code interfaces with various components such as the database, authentication engines, and client side code. They would be the right person to design and implement an external web services API if it exists.
  • Database Administrator (DBA). This is the person who designs, implements and maintains the database for the web app. For small apps the server side architect can double as the DBA, but for very large apps it’s wise to have a dedicated DBA.

Of course, this entire discussion is moot if it’s a one person startup 🙂

Product planning series: Planning a new web app

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
I’ve been working with students quite a bit at the MIT Entrepreneurship Center this semester. One class of questions that keeps coming up surrounds how you actually take an idea and make something out of it. In particular, lots of technical people know how to do the bleeding edge research and get something up and running for the first time, then they get stumped at the point where they have to take an idea (represented in, say, 3 powerpoint slides) and a proof-of-concept technology demo, and take it all the way to V1 release.

Before you start any development work, it is important to frame the program from a business case and financial merit standpoint. The first question to ask is, what is the objective of this whole thing? Whatever the product or service you are trying to develop, you need to have a clear idea of what you are doing and why, and for what set of customers. You also need to clearly understand what you and/or other stakeholders like investors, partners and customers can expect to get out of it. If you haven’t figured that out, you are developing a technology, much less a product or service and especially not a new business around your proposed offerings.

Let’s take a new web based business as an example. Suppose we hypothetically say that “this whole thing” is a novel B2C consumer SaaS play. Some questions to ask at this stage include:

  • What is the market segment you want to target and why? (This forms the basis of your total available market)
  • What are the market problems of this target segment that will drive them to adopt your new offering? What problems are they facing – where are the pain points?
  • What are the defining characteristics of this segment (e.g. demographics breakdown, typical education, household income, all that good stuff”
  • What is the size of this market segment (by headcount, company count or some such – not by dollar amount)?
  • What is the product concept to solve this problem at the 50,000 feet level?
  • What is the likely size of the subsegment that will be addressable by the way you propose to solve this problem? (This forms the basis of the addressable market. For instance, if your offering involves an iPhone app, then your addressable market becomes the part of the target segment who owns an iPhone. Your total addressable market becomes limited by the penetration of someone else’s product or service.)
  • How are you proposing to charge for your product or services?
  • Now put the market sizing information, the pricing structure and so forth in a spreadsheet, run it out for 5 years and do a quick model to see whether you think the economics make sense. Don’t spend more than 30 minutes doing this – the purpose is to use this framework to help you think through factors that matter in the business case. This spreadsheet is mostly worthless as a tool to predict how your business will work because you have insufficient data at this point.
  • Having done all of the above, are you still happy with your idea, who you are serving and what you and other stakeholders will get out of x months of hard work and $y of investor money?

Now we all know the term “MRD” (a.k.a. “Market Requirements Document”) is no longer in vogue. Everybody wants to be fast, agile and not be tied down with piles of documentation. MRD is associated with the waterfall process and that’s very much frowned upon in this day and age. However, in my opinion you just don’t go into any major new initiative without doing some of this due diligence. I am against writing a large 35 page word document, but I do very much support thinking through these key points, gathering any and all facts you can get your hands on, and putting it all together in a powerpoint presentation, and using that as a communication vehicle to achieve alignment at all top level. Without this alignment a development program is pretty much doomed from the get-go – the engineers in the trenches could be working on large sections of code that are based on false assumptions and it would result in nothing but aggravation and frustration in the end.

Only after you have answered the above questions should you proceed to the development stage (which includes product requirements gathering, specifications, design, wireframing, then finally, coding. Coding comes last.) If you go through this thought process and can’t come to terms with what you find out, you should revamp the assumptions that led you to this new offering and pivot or adjust.

Now it is perfectly acceptable to go through this exercise and say “but we don’t know” or “the financials really doesn’t matter because this offering is a hook to help acquire customers for another more lucrative business”. But there is every difference between rushing ahead to do something without thinking through the implications and going into something knowing all the assumptions and facts. I’m a big fan of the latter – it usually leads to better results.

There is a lot more to discuss on how to go about answering my bulleted questions and how to actually plan and execute the development portion of the program. I will be filling in those posts over the next few weeks.

List of posts in this series:

Trust your gut

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
Recently a situation came up at work where we ran into a critical performance issue with one of our key suppliers.  Their performance raised grave concerns, and all the mitigation activities we undertook in the past week did not help.  The work output was simply not acceptable in either quality or quantity.

The ironic thing was that we had concerns going into this relationship.  The supplier came in with glowing recommendations, and they had expertise in a key area that was of vital importance to us.  During the due diligence process, something didn’t feel right.  But they submitted a credible RFP, so we went with them anyways, against our gut instincts.

Looking back, I now realize the warning signs were all there when we were processing the RFP’s.  The performance problems today were foreshadowed by cues we picked up in various conversations.  We picked them due to their domain expertise, but at this point, not only have we not enjoyed the benefit of that, we are also facing the prospect of a large mitigation effort to fix this mess, which meant lost dollars and lost time in the development cycle.

My M.O. in hiring in a time of great schedule pressure has trended in the direction of domain expertise.  But this time I made the wrong call.  I should have listened to our gut and gone for the best athlete instead.  There was another bidder who came in very strong, with a fairly competitive price, but who did not have the specific expertise we required.  I have a feeling that we would be in a much better situation if we had gone with them instead.

Lesson learned: trust your gut. If all logic points one way, but your gut tells you to go a different way, there is usually something profound at work and it’s worth stopping in your tracks and trying to figure out why.

At least we caught this issue early and will be able to address it swiftly – no point in letting a bad situation drag on.


Twitter Updates


%d bloggers like this: