Matching the UI to the User

I recently found an article called "Why I love ugly, messy interfaces - and you probably do too" by Jonas Downey, a designer at BaseCamp. I opened this up because I vehemently disagree. All user interfaces should be as beautiful as possible. In today's age, it's unacceptable to punt those P3 "fit and finish" bugs and ship something that looks ugly. It takes an extra week to delight your users? Do it!

At least that's what I had the mindset of going into this article. What I actually got out of it was exactly in line with my point of thinking, aside from loving ugly messy interfaces.

Matching the UI to the User ...

Old school usability study, behind the one-way mirror

Matching the UI to the user has never been more important. Recently, I was the product manager working on Notarize.com, a new product to enable American's to get documents Notarized in a digital fashion, without the beige carpeted walls of an antique Notary office (at least that's how the one looked like that I went to when I was desperate one day!).

Designing the interface involved designing for an end iPhone user who would likely use this app one or two times in their life, then designing a web interface for the Notary to use, who would likely notarize a document every 3-5 minutes in any given shift, and lastly, for the Administrator to manage notary's and review certain analytics.

On the iPhone, it was super critical to get trust, and friendliness across. This lead to working with the design team to create the simplest UI possible. Fancy animations, great illustrations, a flow that made sense. It also had to get the customer to vest by the time in app before it prompted for credit card and drivers license information (likely drop-off locations). Something that you could use once, or twice years later and still feel like an expert user. Being able to sign, or annotate the document just made sense, and the app helped you along the way.

On the web, we chose the "ugly, messy interface" approach. Ok, so it wasn't ugly at all, it was beautiful! It wasn't super simple however, it leveraged white space for "same page" content delivery. In every 3-5 minute call, the notary would have to review the drivers license, review and edit the document, maintain a video call, and charge the user. Having multiple pages and a simple design would only have lead to long-term frustration for the Notary user. Instead we focused the design on every click needed to perform an action: "add a signature", "add a date", "mark complete", "charge user", "Don't charge user", etc. In fact, we designed the system to just assume that the Notary wouldn't want to click much at all. The system automatically answers the next call in the queue, unless the Notary intentionally marks him or herself unavailable (everyone needs a lunch break!). The drivers license is visible, and directly below the video feed, so you can validate it without even clicking, tabbing, or hovering (but you can hover or click if you need more detail). I.e., the interface was optimized around speed, knowing that the notary would get some training, we optimized the UI for the expert.

The admin console was targeted at frequent tasks, reviewing analytics, and less frequent tasks, adding or removing notary agents who work at the company. As a business starting out, it's likely the owner would have that dashboard open much like a real-time dashboard for a rocket launch. We designed for this persona as well.

All this is to say, is that each part of your product, think of who will be using it, and what their needs are, and design for that. Jonas talks about the Craigslist UI, but users can find what they want, they don't have to search, it's look, and click, no searching or figuring out how to use the UI. He also talks about the Photoshop UI, again, can you imagine how much clicking it would be for a digital artist if this was a simple design?

On a last "devils advocate" note, working on Small Business Server 2008, we wanted to target the DIY or "Do-It-Yourselfer" as the system administrator, but also enable the paid consultant. More time was spent trying to figure out how to make the UI work for both audiences than I care to sum up. Looking at the product now, it just looks like it's for new administrators, missing both marks. There are very little DIY people administering the software, and most of the consultants use the standard server consoles. Ultimately, targeting two audiences just alienated both of them.

While Jonas hits a great point, it's not that we like ugly, messy interfaces, its that we like UI that's targeted to our use cases, but we want it to look beautiful, right Jonas?

How are people using your product?

Kudos to the MetaLab team who pulled this together, such a great team of designers, developers and QA. Learn about the Notarize product here - http://metalab.co/projects/notarize/ 

Read More

What Just Happened? Let's Talk Post-Mortems

Today one of my favourite "celebrity" Product Managers, Ken Norton, published a quick and dirty article on Bring the Donuts called Blameless Post Mortems. This spurred a thought process for me on the importance of review.

There are two important times to look back, and the both have different ways of approaching them.

1. When there was a clear service failure, it's important to figure out what happened, and how to prevent it from happening again.
2. When finishing a long running (3-5 month) process or project,  extracting the learnings from that to apply to future projects.

In Ken's Post Mortem document, the former is what is discussed. When something break, it's important to conduct a review, in a blameless fashion, and figure out how to prevent it from happening again. 

Service Failure Post-mortems

Often when there is a service outage, a security hole or some notable problem in a service it's important to review in hopes of preventing it from happening again. With the right process in place, repeat outages can be prevented from happening again, although in some cases, the outage may not be preventable, or not immediately preventable (i.e it may take weeks or months to re-write part of a service to prevent it from happening again). However in many cases, simple process or diligence can increase service reliability. For example, code reviews with senior developers, or security audits with least privilege assigned to operational folks. 

Ken points to a template that Google uses for this purpose. This is essentially the same template that is used at Microsoft as well, so it's definitely a good source. The idea of the template is to just work in a group of experts on the specific issue to fill out the template, track the bugs found through closure (code fixes, or process fixes), and share the knowledge with everyone on the team to ensure it doesn't happen again. Then move on and learn from that experience to the next outage, rinse and repeat.

Shipping Post-mortems

The second type of post mortem usually happens at the end of shipping something substantial, or if it's continuously shipping, they can be done every 3-6 months. It makes sense to run to connect a post mortem to something substantial: i.e. a new multi-sprint feature out the door, a retrospective of trying out a new tool, or a 3-5 month anniversary of a team being together are good examples. Preferably the retrospective is not too far away from the start of the project, that the project starting bumps can still be remembered, and not too close that the team hasn't hit cadence or shipped something.

This critical post mortem helps discover what's working for a team, or where a product manager and/or leadership should focus energy on change.

Sticky Notes are your Friend

This type of post mortem is run differently than a service outage, and likely will take up more time to complete. A good rule of thumb is the moderator, often a product or project manager, should put aside about one and a half to two hours of time, while the rest of the team can join for an hour plus brainstorming. Here is how to run this type of post mortem:

Preparation

Brainstorming takes time, for some it takes a short time, and for others it takes a longer time. For maximum meeting efficiency, it's best not to do this in the post mortem meeting. When the 1-hour long post mortem time is published, the moderator should ensure each person attending comes up with 1-3 things that went well, and 1-3 things that could be improved, and if possible a suggestion or two on how to improve each. Brainstorming should be completed before the meeting starts to make the meeting as efficient as possible.

Execution of the Post Mortem

The execution is where sticky notes are excellent. Most of the meeting will be run by moving sticky notes around, grouping them and positioning them in priority order. In a worst case or a remote case, a whiteboard works as well (i.e. remotely accessible meetings can be run by screen sharing using a digital whiteboard or a shared GDoc/Evernote file. It's probably most efficient to have a typist who is separate from the moderator). 

Here is the suggested timeline of the meeting:

• 5 mins - Introduction and adding prepared 1-3 pros and cons to separate sticky notes
• 10 mins - Team sorting of all the sticky notes on a wall/whiteboard and grouping similar items together, prioritizing the team top 1-3 pros and cons
• 15 mins - Discuss what went well (the pros), and why we should continue doing those top 1-3 items as agreed by the team
• 30 mins - Discuss the top 1-3 items that could have gone better, what can be done to address them, assign action items to people to track resolution

Let's break each of those timeline items down:

The first 5 minutes of the meeting is just paperwork. Members write down their top 1-3 areas that went well and top 1-3 areas for improvement, each on it's own sticky note, no need to write own how to improve these at this time. Each member of the team now has 6 sticky notes. In some cases, members come with more or less, you can choose to include them or not, it just makes for more paper and longer discussions. What has worked well is to really focus on the team top 1-3 items for this post mortem, then at a future post mortem (3-5 months down the road), tackle the next level. This is a reasonable amount of change for the team to handle in that period of time.

The next 10 minutes of the meeting is about review. Each team member reads out and hands their stickies to the moderator. The moderator is responsible for grouping them together, stack ranking and ultimately by the end of the 10 minutes, the group collectively has the top most agreed upon "team" top 1-3 things that went well, and the "team" top 1-3 things that need improvement. 15 minutes has passed and we're now set up for success for the rest of the meeting. This process ultimately leaves a handful of things to take note of, but aren't considered for active change as outcome of this meeting.

The next 15 minutes are focused on the things that went well, or the successes in the project. While everyone likes to celebrate successes, it's ultimately done to ensure that when we are correcting for what didn't go well, we don't lose site of the things that actually made this project great! They are captured for historical purposes as well. Was the communication tool the best part of the project? Was a process for less than 2 hours for code reviews beneficial to the speed the team ran at? Was having a spec-let a good thing? Let's do the good things again. This section may even be less time, which is great, because the heart of the meeting is next.

The final 30 minutes of time are focused on the top issues that need addressing, this is the meat of the discussion. The team collectively looks at the "team" top 1-3 and actively discusses ways to improve during the next project. Items like "The bug tracking software was a bear to work with!" might result in a project manager assigned to review and recommended new software packages to track bugs. Another example might be, "Our communication software lost track of the decisions we made, forcing us to re-make decisions a month later", might result in a process to document decisions outside of chat tools once they are made. Lots of good ideas will come out from people who didn't even have this as an issue, which is why it's optional for the person suggesting the area for improvement to actually come up with a solution. Coming up with the solution is a team effort.

Lastly, as part of that last 30 minutes, it's likely that most if not all of the key items cannot be finalized in the 1 hour meeting. It's irrational to think you can pick a new bug tracking software in this 30 minutes for example. As such for each change we need to assign a BOL (aka a Butt On the Line) to drive that issue to closure. That person owns the research, delivery and communication of status of that. Depending on the organization, that BOL may have the authority to make a change, or simply just make a recommendation, either way, communication is warranted.

When the execution phase is wrapping up, the moderator will want to capture the notes, either a photo of the sticky notes, or a good note takers notes are fine.

Follow-up

After the post mortem is done, the information needs to be shared, a good moderator will take the notes of the top 1-3 items that went well, and the top 1-3 items that need improvement and write up notes on how the improvements are planned to be implemented and who the BOL is. As the BOLs get resolution, they can even follow-up to the original communication with the changes. The format of the notes should be titled with the project, have the date range that it covered and who attended the meeting. Then jump into what went well, and then what could have gone better, and how the team suggests to improve it, with the BOLs assigned to each item. 

Keeping the notes as short and crisp as possible is important, since the moderator should share the learnings outside of the immediate team in places such as a company Wiki, a broader email to a group of leads or in a specific chat tool. The key is to match how information is spread at the company.

---

This post mortem method really helps the team celebrate wins of working together as team, as well as helps the team focus on improving together, where everyone has a voice. It's also a great indicator for the leadership team on the health of the core of their business and where leadership should spend effort. Effort might include replacing core technologies if they aren't working, or finding key talent to improve knowledge or just ensure their team is staffed appropriately.

As a parting note, while it seems there is a lot of effort that goes into a post mortem, it's important to learn from mistakes and from successes and not repeat them. The hour or two invested here often save hours in the next project, and potentially retain your talent. Frustrated talent looks for less frustrating circumstances.

Read More

Product Managers Should Know Their Customers - No Excuses

Product Management is usually a role that is customized to the organization in which it exists. As such it's extremely hard to explain a product managers role. I usually share this link to friends and family who ask the famous "so you're 'in computers', what do you do?" it's written by Martin Eriksson. Here is the simple version of you as a product manager:

That's right, the pinnacle point of the cluster f--k.

Many people read this diagram as the product manager being involved in the decisions as it relates to UX, the tech decisions, and where the business is going. While this is very true, a product manager is also a supportive role. What that means is the designers, developers and business leaders will have questions, a lot of questions, and it's the product manager's job to answer them or find an answer, somewhere. 

Finding that answer may come from inside the company, but as a company grows, it'll be harder and harder to find the right person, or worse, answers may differ between different business leaders. Having multiple opinions will create a broken user experience in the product. The product manager normalizes the feedback, collects more, and combines it with long term direction creating a cohesive story for end-users using a product.

So if not all the answers come from inside the company, where do they come from?

Customers, Customers, Customers.

A product manager should know exactly what their customers want, at all times, about each key feature in their ownership. There is no excuse, except perhaps for initial for ramp-up periods. A product manager brings the voice of the customer to the table. It doesn't matter if the product is supposed to make millions (a.k.a. "Business"), it looks beautiful (a.k.a. "Design"), or is a masterful architecture of tech-greatness (a.k.a. "Tech"). If it's not targeted towards a market and a set of customers, it'll end up in the bit bucket.

So a product manager needs to know their customers, deeply. How is this accomplished? Research, and lots of it. I particularly like this article about the breakdown of Qualitative and Quantitative research, to help you once you get the data. I like to get my data from many different sources, here are the top methods for getting data, in order of most often used:

1. Telemetry - Data-mine the heck out of the product as it provides daily insights! What are customers using,? What are they not using? How long is it taking customers to go down a funnel? Where are the drop off points? What does A/B testing tell you?
2. Support - Current customers are calling to tell you what's broken, what they want, what they need. Pick up a phone and listen. Follow up with some of the more interesting ones that align with business the business direction.
3. Sales - Potential customers are on the phone as well, what do they want? Why didn't they choose your product? Why did they? What would make it a slam dunk for them next time around? What competitors are they considering and why?
4. Round Tables/Advisory boards - Get your key customers in a room together, or on a webinar and let them voice their favourite features (don't mess with this, or improve incrementally for low-hanging fruit), and their feature wishes and hated features. Let them talk to each other as well.
5. Conferences - Not yet potential customers who could be potential customers, who may have never heard about the product or company. Get their reactions, what do they like, what don't they like. Are they extra engaged on key features, do they call out features that should be there? And my favourite, let your customers sell other potential customers on the product and see what they think are the key features.
6. Site visits - Just like a lion safari, watching the users in their natural habitat is irreplaceable. Watch where they get tripped up, ask them why they chose one way over another way. There is a lot to learn. The caution on this one is to make sure you do multiple site visits so there isn't an overly tailored and specific request for one customer, geographic or vertical.
7. Calling or E-mailing - Calling works better than email (less noise these days), but simply calling a customer with a question or two, and potentially a perk to get their attention (1 month free for example). A ton of insight can be gained by talking directly to a customer.
8. User Studies - These are expensive, but super informative to study behaviour. It's like bulk sight visits sitting behind one-way glass. You often need a person or company to find and orchestrate the study on behalf of your company. If you do this, attend a number of sessions, it's completely eye-opening.

There are many ways to connect to customers, these are my favourite eight. The absolutely key thing in all of these is to listen, and then listen some more. Then take notes before the memory fades.

Lastly, once the customer is understood, to help other disciplines understand the customer, it's not a bad idea to put together a single page for the persona(s). This single page is an "average" customer that takes the 100s or 1000s of customers met, and makes up about 80% of their needs, wishes, and thoughts. 

I like to print these out on a piece of paper and stick them up around the office. They have a "fake" name and picture, details about what they do and care about, enough to get the other disciplines aware of who they are building for. The plus is if an engineer needs to make a snap decision while the product manager is at a conference or site visit, they can do just that and get it 80% correct!

Got a suggestion on how you like to connect to customers? Drop it below.

Read More

When Should a CEO Hire a Product Manager?

A company usually starts with an idea, or a couple of people getting together over an idea. That idea percolates and becomes the center of attention for the founder(s) or CEO. Obsession over details and getting things just right is the norm. This is all goodness. Hopefully that obsessive effort takes off and the CEO is forced into running a business, instead of nursing an ember of an idea.

I have never been a CEO of a company, but I've watched them. The responsibilities seem endless. Build the right team, which means hiring and interviewing. Keep the VCs happy, which means flights and travel and presentation prep. Go find the customers and evangelize, more travel and more presentations. Make sure the company can make payroll, reviewing the finances and financial planning. Prioritizing the companies limited resources to get the biggest bang for a buck. There is a lot more than that, but even those alone seem like full time jobs. Some of this is easier if there are co-founders and division of duties is forged. But often co-founders have the same vested interest in knowing all the details of the business, and thus never fully leave the other to handle their tasks without at least being in the know.

All this, then a developer wants to know what should happen if a user taps the help button. The product needs help, but who's going to write all that content and figure out the user flow back into the app?

The CEO's job is to focus on the big picture, the big moving parts and the future of the company and product. You've heard the phrase "Hire to your weaknesses", but the CEO often doesn't accept that a lack of time is his or her weakness. Or often feels that since the idea was theirs, no one else will understand it. Building a software product and worrying about the details takes time, and lots of it. It's not accepted today to ship something where the details aren't thought out, a single bump in the user experience can cause 1,000s of users to jump to your nearest competitor. Moreover, that bump is what they remember about your product, it'll take a lot of work to convince them to come back as they think of your product as unpolished.

The CEO needs help, but how do you know when? Here are some signs a CEO should look to getting a product manager as soon as possible to help build your product:

1. You find features in your product that you had no idea were even in planning
2. You haven't used your own product in the last 2 or 3 releases
3. When you do make it into the office, there is a line developers outside your office waiting for you to make a business decision for your product
4. Each email you get from internal employees starts with "Sorry to bother you again, but ... "
5. You feel the momentum of development has slowed down, and developers don't have butts in seats coding up a storm
6. You find a product request from an important client that's three weeks old and you haven't mentioned it to the team yet
7. Your development team is telling you which features they want in the product and most of them are over half completed

In many of the above examples, the development team is missing the product direction, the answers to what's next, or what business decision happens at this stage of the user experience. The day-to-day of product management!

One thing I've learned about developers, is they like to code. If there is nothing to code, they will make something up to code. This doesn't help the company, and it doesn't help the end user. My worst nightmares are when developers don't have customer features to build, so they wish to re-architecture the product. While a refactor is necessary from time to time (future post on this topic), it's a lot of development and engineering with very little end value for the end user.

Without product direction the direction of the product turns from a targeted, to shotgun approach. The long term vision of the product that customers can visualize disappears. You end up with a lot of features that are indeed nice to have, but don't add a lot of value to the end user. Such as:

1. A forever changing foundation of the app or service bent to whichever developer has the more convincing argument at the time
2. A set of unpolished quasi features that loosely fit together, instead of a cohesive vision of intended value
3. Broken flows across pillars in your organization (aka, the org chart is showing) making users stumble around inside the product
4. A lack of investment in larger customer requests
5. Slick animations in areas of the product that are rarely used

... to state a few.

When a CEO finds themselves too busy to keep the product moving along at an acceptable pace, with features directly targeted to the customer, it's time to think about a product management role. Essentially, as soon as the CEO can't spend more than 50% of their time worrying about product direction.

Find a product manager who shares the vision of the product, and spend a lot of time with them. Initially, a huge amount of time. Let them play with the product, then spend more time with them. Lastly, bestow them on your dev team and watch the magic unfold. The CEO will walk away with more time, and a better product as a result.

Once hired, it's important to keep the Product Manager and CEO in sync at a minimum on a weekly basis. I could write more on that, But The PM Mind Meld by Ken Norton tackles exactly that.

Read More

Why Product Management Should be a Separate Person or Team

I've seen lots of teams and companies try to overload the product management role onto other disciplines. Often the CEO, CTO or a set of developers, or in best case, designers take it on. The problem with doing this is conflicting interests.

The CEO is interested in bringing his or her vision to life, yes, but often doesn't have time to deeply understand the customer, aside from themselves. This often results in a product that serves one person, or a set of people that are almost identical to the CEO in desires. With so many other demands on the CEO such as sales, evangelism, team building, financial analysis, and market analysis, the CEO can't do it all. This leads to developers coding ahead of the CEO and eventually into developer driven design. While it's great to have input from the CEO, product management should quickly be handed off to a dedicated resource.

Technical roles such as developers or CTOs often want to take on the product management role, or often surge forward when the CEO is busy with their own ideas. They are focused on the technical debt and technical challenges they see. This will no doubt increase the value of the product, but usually not in ways customers see it. Customers don't see changes in framework, or how quick your continuous integration is, or updated support tools. Developers often direct products again in the ways of cool tech to work on, or hard technical challenges, without actually understanding what impact those parts of the product will have on the customer. In many cases, such as a changed out framework, there is no impact to the customer, and months pass without bringing value to the people who are paying.

The closest role that can help shape the product is a pure Designer; more so if that Designer is product minded. Designers bring a lot to the table regarding ease of use and aesthetics of the product. However, they tend to focus on design principles and solving the problems at hand. Designers are fantastic for taking part(s) of a long term vision and executing on the near term, but many designers won't think about the long term goals and product strategy. They focus in the weeds of what's in the next release, does this have to be a text box, or a drop down, and where does it go? While design execution is extremely important, it doesn't satisfy the need for a cohesive long-term strategy for the product.

The product manager role, separated from other disciplines, enables a long term plan by defining a story. Product management also brings the customer voice to the table, it leverages customer feedback, and other information to build a product road map, and product goals. Product management focuses designers and accelerates developers on what's important now, what to plan for in the near term, and what to account for in the long term. Product management also has the ear to the ground for changing market conditions, and can help adjust the plan when the long term market is adjusting.

Input from the CEO, developers, designers and the rest of the company is still important, but a single person to own the strategy and vision will build a cohesive product and ultimately save time, and delight customers with a plan in the long run.

---

My favourite example of engineering run design is Windows Update from Microsoft. Albeit Windows is a large platform, and there is a strong desire to both keep Windows secure, while at the same time make it easier to maintain, there is a clear missing voice of Product Management.

I can tell this is engineer driven because the easy engineering road is taken, and it's irritating to customers. While the concept of "Patch Tuesday" was defined around this made it easier for system admins to plan for patch updates, it's terrible to think that this concept even has to exist. The personal computer should be doing whatever it can to make the person successful. The person shouldn't have to wait on maintenance, or updates when they want to use their computer, those should happen in the time the person isn't around. I mean humans do sleep for 6+ hours a night, more than enough time for computers to maintain themselves.

The reason that a reboot is intrusive is because no one or no team at Microsoft has taken the effort to figure out dependancies between components, as such when taking down a small service to update it. The teams at Microsoft have no idea what they might be breaking in other teams services, so they reboot the computer, a.k.a the easy path. Then once they know things are patched, they start all the services, when in reality, it should be something that the computer can just save the users state, restart a small service, set of dependant services or apps, and be invisible to the end user. If there was serious Product Management on Windows Update, and in the case of large enterprises, that Product Management team had executive support (aka, Satya or EVP of Windows, Terry Myerson), things will change for the better for the end user, to the tune of "Wow, my Windows computer never reboots!"

Read More