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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is the sixth post in my Product Planning Series.

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

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

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

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

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

DO

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

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

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

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?

I have mixed feelings about mobile products from Apple.  On the one hand, they are gorgeous.  The hardware is well designed and manufactured, the software interface is fabulous, and the user experience simply delights.  On the other hand, they are made by Apple, and I have a serious problem with their business practices.  

Apple’s closed ecosystem completely turns me off.   But it’s the experience of doing business with Apple on behalf of a previous employer that has permanently soured my ability to truly enjoy Apple products.  To this day I cannot look at an iPhone or an iPad and not get flashbacks.

This is why I carry an AT&T Samsung Captivate running Android 2.2 (Froyo), and conduct all my business using Google apps on my phone.  Samsung and Google are two brands that I dig.  I find Samsung to be almost as good as Apple in hardware product design.  Their mobile business unit is highly innovative and the Galaxy and Galaxy II lines are fantastic.  The cosmetics, fit and finish of their phones are impeccable.  I like their oversaturated displays – even my friends who are die-hard Apple fans have had to concede that the 4″ AMOLED display on my phone is more vibrant than their iPhone 4 display. And It’s Not Apple.  

As for Google, I can’t exactly remember life before Google Apps.  Even my grocery shopping lists are kept as a Google Doc.  And That’s Not Apple, either.

This personal hangup explains why I did not get an iPad2 the minute I decided I needed a tablet device.  Instead I spent weeks researching available choices: Acer Iconia? Asus Transformer? Motorola Xoom? … etc.

I ended up convincing myself that the Samsung Galaxy Tablet 10.1″ would be the right choice for me.  This thing looks breathtakingly on paper. It’s the same size and weight as the iPad2 (thinner and lighter by a hair – not a meaningful differentiator), but it’s not made by Apple.  

So I eagerly waited for the device to come available at my neighborhood Best Buy on Friday 6-17-2011.  I ran to the store on Saturday in order to play with one, benchmark my experience against the iPad2, then buy the Samsung tab.  I thought it was a shoo-in.

Instead, I found that the device was stunning in every hardware detail… but (GASP AND ALAS) I liked the iOS experience on the iPad2 far better than the Android Honeycomb 3.1 experience on the Samsung Galaxy Tab.  Honeycomb is a fine OS, but it doesn’t hold up a candle to the usability of iOS 4.  And we’ve all read about the wonderful advances in iOS5, coming soon to an Apple device near you.  So I went home depressed… and ordered an iPad2 on line.

If ever there is a cautionary tale about the fickle nature of brand loyalty, this is it. I really, really wanted to get an Android tablet, made by Samsung.  But in the end, the better product won.

Moral of the story: invest in the user experience.  Make it delight the end users.  It will pay off in the end.

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.

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

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 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!)

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!

• Nielsen wire – online and mobile – RSS Feed
• Nielsen wire – consumer – RSS Feed
• IDC Press Releases RSS Feed
• NPD Group Technology Press Releases RSS Feed
• NPD Group Press Releases Rss Feed
• Gardner Research Press Releases RSS Feed
• Juniper Research Press Releases RSS Feed
• Comscore Voices RSS Feed