Archive for the 'Software' Category

“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.

Advertisements

“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: Information Architecture, Flowcharts and Wireframes

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

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).
Example Web Site

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.
Example Wireframe

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.

Example 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.

Product Planning Series: From use cases to storyboards

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

My approach to product development revolves around user-centered design. The basic tenet of this philosophy is that the product team must be equipped with a thorough understanding of the end user’s needs, wants, expectations and limitations in order to create an excellent product solution to solve the user’s problems.

This understanding begins with user personas at a high level and becomes fleshed out via use cases and user stories.  The UX design team can then ideate on a solution to the problems the user is trying to solve and create storyboards to imagine how the solution may be implemented in the context of the product.

The words “use case”, “user story” and “storyboard” can mean different things to different people.  This is what I mean when I use these words to describe the tools and artifacts I use in the product design process.

  • Use case: A high level thought experiment of a workflow from a user’s perspective.
  • User story: A brief description of a part of a use case or storyboard that succinctly defines a task the user has to complete, from the user’s perspective, with no assumptions placed on design or implementation. Used to describe functionality that will go into a backlog to be prioritized and managed by a product owner (in classic Agile methodology)  It is usually much more granular than a use case and describes a snippet of what the user needs to do to complete a workflow.
  • Storyboard: An output of the design process that illustrates the experience of the user in a journey to complete a workflow using the product. In my experience, this is the fastest and most effective way to turn a high level UX idea into something concrete that the product management team can use to test with customers and the product development team can use to plan their work.
I find that these three things are fairly universal in their applicability to all kinds of products, hardware and software alike.   In cases where the use cases are complex and the solution is non-obvious, it is vastly faster and cheaper to iterate a design idea at the storyboard level than to code it up and then review the actual working code output.
With the right talent on the task, one can literally come up with 5 or 6 storyboard iterations in a single day without investing in any engineering development.  The impact on software products is substantial – it can take weeks to program just one of those iterations, so storyboards saves time and money in a tangible manner.  The impact on hardware products is game changing – a single iteration for a hardware implementation could take months or longer.  Storyboards allow the product team to iterate, test and learn, so that we can come up with a better end result in a shorter period of time with the least possible investment in engineering development.
Once the product design is vetted at the storyboard level, it becomes much easier to fill the rest of the design gap with a detailed design solution, and development will then be able to implement the design efficiently and effectively.

Product Planning Series: Project Management

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

Bringing up a new web app is much more than a technical project management effort.  Any new product or service development program is a massively interdisciplinary exercise.  In order to have a successful outcome all affected constituencies will need to be involved in developing the program plan, so that key milestones and dependencies are identified from the get-go and actively and aggressively managed so that there will be no surprises halfway down the line that will result in a significant project delay.

Here are some of the interdepartmental milestones that need to be worried about for our consumer SaaS example.

On the customer research / persona development side:

  • Product discovery research done – target persona(s) chosen and fleshed out
  • Needs, wants and expectations fully understood for target personas
On the business planning side:
  • Finalize pricing structure
  • Finalize channel strategy (for our example this is direct to consumer, which makes life very simple indeed.)
  • Where applicable, develop ROI analysis for target customers (this will be used by product marketing to convince prospective customers to adopt the product or service)
On the product planning side:
  • Product strategy fleshed out – this basically describes the product concept that solves customer problems
  • Basic product roadmap developed with some idea of phasing of which problems to be solved when and how over the next 12-24 months (I like to make a 1-2 year actionable roadmap and a 5 year vision roadmap)
  • First pass definition of minimum viable product (MVP) complete (this is a hypothesis based on customer learnings to date)
  • User stories developed (this usually requires a second round of customer research) – a paragraph per story
  • Key user workflows fully mapped out at least to the flow chart level (this is particularly important if you are developing something for a target user persona that is not readily relatable by your program team.)

On the design side: (these milestones are specific to my consumer SaaS example. Some other day I will write a different post for hardware products.)

  • Determine high level navigation architecture (what are the organizing principles of the information and actions you can take on this web app?
  • Wireframe key pages to illustrate workflow
  • Design a few example pages to “put the breadcrumbs closer”

On the technical side:

  • Development platforms chosen
  • Server side architecture design finalized
  • Server set up, ready for development
  • First proof of concept with rudimentary UI showcasing any high risk items that needs to be investigated (e.g. if you were testing out a brand new private video streaming service that has just come on the market)
  • Key third party technologies integrated (e.g. shopping cart, knowledge base, etc.)
  • Intermediate internal releases as parts of the app comes up for testing
  • First instantiation of the MVP (minimum viable product) with a relatively complete user experience, released for beta testing
  • First release of the MVP (start to charge for the service!)
On the customer research side:
  • First set of product discovery interviews done, ready for persona development
  • User workflows vetted with users at the wireframe/storyboard level
  • Customer Advisory Board (CAB) assembled, ready to advice program team on features and benefits
  • Continuous testing of intermediate releases with CAB members
  • Usability study of implementation for key workflows (Do some in-house lab testing with fresh subjects – not CAB members, and do some across a broader audience with services such as www.usertesting.com)
On the product marketing side:
  • Design and develop content and assets for landing pages, conversion pages, etc
  • Develop PR strategy to get the word out (for this example, work should be done well in advance to get key blogs to cover the launch of the web app.  Facebook page should be set up with appropriate content and prepopulated with fans drawn from the early tester community.)
  • Decide on, and execute, any one-time campaigns to promote the release (e.g. email campaign)
  • Develop any product collateral (e.g. quick start guide, user manual, video tutorials)
  • Update any corporate web pages ahead of time for a coordinated launch activity
On the business development side:
  • If applicable, business development activities to land partners will need to carry on in parallel with all these other activities. For instance our music app for small children might benefit from having Suzuki string teachers on the roster to provide expert answers.  The business development activity for this app would then involve recruiting and engaging these partners.
On the customer support side:
  • Determine customer support policy – first tier, second tier, email / phone coverage, languages and hours supported, turnaround time, etc.
  • Develop on line help / FAQ (this could be done entirely via a searchable, hierarchical knowledge base)
On the legal / regulatory side:
  • Develop end user license agreements / terms of use
  • If applicable, obtain regulatory clearance if the product or service requires it (our example does not require anything, but a medical site that, say, provides diagnostic guidance to various illnesses might have to look into FDA 5(10)k)
There is a lot of work that goes into developing a new business and many different constituencies are involved.  A little bit of planning up front goes a long way towards helping to make the program a success (and to minimize the level of stress in the development process).

Mobile/online analyst feeds to add to your Google Reader

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
The other day I was having a conversation with a team who is working on a mobile app. I started spouting smartphone OS market share statistics and trends, and reproduced these (slightly stale) comScore chart on the whiteboard from memory. (By the way, that’s nothing special – any product person in mobile can reproduce 10 such analyst charts on demand.)


The team asked me where I got this data from and how much it cost. Well, it is free (assuming you don’t pay yourself for staying up to date in your own industry.) Simply add the following feeds to your RSS reader of choice (I use Google), and scan the press releases as they come in. All the analysts put out press releases when they have a report coming out. Additionally the mobile industry numbers are crunched and released every quarter. There is no better way to stay on top of the massive flow of data by sipping it a little at a time with your morning coffee. You will know which smartphone OS is on top, which handset manufacturer is winning, what the US market looks like compared to rest of world, etc. Happy reading!

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: who, what, why, how

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the second post of my Product Planning series (which uses a new web app as an example to illustrate how you go about planning the release of a new product or service.)

In my last post I outlined some of the questions that you should ask to establish a business case for your new product or service. Once that’s done, it’s time to define who you are building the product for and the problems they face, what your proposed solution looks like, why you think it is better than anything else out there, and how your solution will work to solve these customer problems.

Who
The first question some people ask is: why segment and target? If one does a wonderful job with product development, shouldn’t the product sell to anyone who might find a use for it? My answer is this: it is not possible to develop a wonderful product without knowing who you are designing it for.

Let’s say our web based B2C consumer SaaS offering is an educational site for children that focuses on advancing the musical education of kids who are learning an instrument.

Right away we can see that the buyer (a parent, grandparent or teacher) is different from the user (a student). You will need to build a buyer persona and a user persona. The buyer (parent) wants the child to learn. The user (child) just wants to have fun. To be successful the product must both educate, to meet the needs of the buyer, and entertain, to satisfy the wants and expectations of the user and to ensure stickiness and compliance in product usage.

If the word “persona” is new to you, Pragmatic Marketing has an excellent article explaining the persona concept, and Scott Sehlhorst has a great article on this topic. You can also consult my post on using ethnographic techniques to develop personas.

The purpose of developing the persona is to use the target buyer and user to help decide what to build and how to present it. What age group are we targeting – do you need to cater to the pre-reading crowd? How high do we go in the age bracket? These affect the user interface and use cases because clearly a 15 year old violinist playing first violin in a youth orchestra has vastly different needs and wants than a 5 year old violin novice working on basic bowing techniques.

Persona development goes far beyond demographic information and goes deep into situational scenarios. What is it like living in the households of these music students? What is their daily schedule? How long do they spend on music practice each night, and for how many nights a week? When do they practice music? How involved is the parent? Are they distracted by their siblings? What parts are hard to learn? What are the objectives of the child and what problems does he or she face? What are the objectives of the parents and how do they measure their child’s success?

A good persona provides demographic and psychographic information, as well as additional information about the attitudes and motivations of the persona in the area of product use. It is well worth the initial investment to develop a good set of personas, then clearly delineate the problems they face. It will help make development more efficient down the line and help you develop a great user experience that is tailor made to your target end users.

What
Once the buyer and user personas are defined, and their problems are well understood, it’s time to figure out what the solution to these problems might look like. For example, it is very hard to motivate a young child to learn all those pesky Italian musical terms. Perhaps an on line memory game might help them remember those terms. Another example is that the child may need to work on posture. Perhaps a video feature that allows the parent to take a video with their cell phone, then upload to a server and share it privately with the teacher might help. A third example is that the child has forgotten the correct technique 3 days after the teacher demonstrated it. A video snippet of the lesson might just do the trick. And having this all in one place encourages usage and compliance.

As a product team comes up with solutions, there are invariably way more ideas than what would fit in a desired timeline. Here is where the persona will be useful: the product team can use the persona to help them imagine what is of the most use to those personas, and develop a release roadmap where features that deliver the most benefits and value are released first, followed by other features that either broaden the offering or offer secondary benefits.

Why
Many wise product and startup people, including the folks at Y-Combinator, have commented on the need to focus on the customer, not the competition. This is very true. However that doesn’t mean you get to punt on doing a thorough competitive analysis to understand exactly what is out there in the market. This helps you in several ways:

  • You can check to see if your solution really solves an unmet need. If to your chagrin you find something that solves the problem quite well, it’s better to know sooner than later so you can pivot to solve a different problem that REALLY represents unmet needs.
  • You can learn from the successes and failure of other people who were in the market before you.

With a good understanding of the competition you are well poised to articulate your competitive advantage which is necessary for developing an actionable and meaningful positioning statement.

How
Interestingly, many technology startups start with the “how” as the basic premise for starting a company. Someone comes up with a brave new technology, develops a prototype for it, gets it to work, falls in love with it, then sets off starting a company with a field-of-dreams business plan.

That works sometimes if the technology is really world shattering. In consumer SaaS, the technology itself is sometimes commodity software. So for those types of products, the “how” comes only after having figured out the who, what and why. The “how” is concerned with how to actually implement the solution. For this example, you would pick the technology platform to develop your new site on – fielding considerations such as open source versus proprietary platforms (my vote: Open source), database of choice (I like MySql), programming platform (for complex web apps: Java EE back end with Javascript or HTML5 front end; for quick hacks, I like Ruby on Rails). You will need to make decisions early on about hosting and server care and feeding too: certain platforms bring a hefty server side license fee and you will need to account for it in your projected server fees and expenses.

Once the platform is picked, you can now work on defining and designing the product in detail, staffing up for success, and executing the plan to bring your offering to market in the desired timeframe.

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:

Open source v. Microsoft

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
Lately I found myself in the middle of a discussion with a client about which web platform / architecture to choose for a new SaaS project.

The web app itself is eminently doable on any platform, and is not all that scary from a technical difficulty standpoint.  The client is very much adopting an MVP approach and there is buy-in across the board to tightly control what gets in for V1 so there won’t be huge feature creep.   While scalability is a consideration they believe they will roll it out in a measured pace in the initial months, so it is not necessary to plan for, say, 5 million uniques and 15 million page views in a month – they have no plans to push the traffic while they are in learning mode.  So there is time to learn and adjust once the app is launched.

If there is no development history to the project, everything could have been handled with open source technologies.  Drupal could be used as the content management system for the marketing stuff, Java / Ruby / Python or even php could be used on the server side, and one could use MySql or Postgres for the database.  One never has to worry about exploding server side license fees if one stays away from IIS, .NET, Microsoft SQL server and stuff like that.   Open source platforms are great if you have a pronounced need for speed. There are many reusable open source code libraries one could leverage.   Lastly, all the cool kids want to do Ruby on Rails these days and it is much easier to recruit for a Ruby developer than a C# developer.

Alas, there is actually quite a bit of history that complicates things. First of all, there is a legacy Microsoft SQL database with an existing schema, much of which is applicable to this application, and it would be highly advantageous to be able to migrate it instead of having to redo it all in another database.   So moving away from MS SQL doesn’t seem to be advisable.  Second, and more importantly, this company is a Microsoft shop. The development and operations talent in house are all world-class experts in .NET/C++/C#.  This made the decision process very non-obvious.  Do we choose a hot new platform so we can build it quickly with external resources, only to go through a steep learning curve later when this new work is brought back in house?

This is a head scratcher for me and I am actually not sure what I would do if it was my team.  I think I would lean towards picking the trendy platforms.  I probably would plan on hiring at least one new senior or principal level developer who is highly experienced in the new platform, and retraining those who are able and willing to share custodianship for the new platform.  But it is as much a budgetary and human resources consideration as it is a technical decision.  The best technical decision could be an ill advised business decision in the long run.

What would you do if this was your team?


Twitter Updates


%d bloggers like this: