Blog Post: Lazy Users Are Actually Efficient

Having orchestrated many user testing exercises, I have lots of experience with user laziness. It is a term in the product world that refers to users skipping all of the precious copy and walk-throughs engineered with love. With such well-written copy and care given to every interaction users have with our products it’s understandable to get upset watching someone skip over all of that and just get to the meat of a design.

I can’t tell you how valuable that kind of information is.

Often, we get so concerned with designing a product “right” that we overlook the obvious. This blog post from UX consultant Harry Brignull perfectly illustrates just how unnecessary some product decisions are:

If you tell it to work out 200 factorial minus 200 factorial, it will do a lot of unnecessary computation, and perhaps produce an overflow error. The intelligent solution is a far more lazy one.

That means the many screens describing what your app does may be a waste of time to users. They can figure it out on their own. Instead of utilizing an account creation module with four or five screens, just add a Facebook login button. The data you get will be the same and users will be happy they didn’t waste a few minutes for an app they might not like in a few weeks.

Examples span every industry and product alike. Instead of seeing users as lazy, we must take the data they give us and streamline the experience of our products. When we have an efficient method of giving users what they want, they appreciate it and come back for more.

Blog Post: Lazy Users Are Actually Efficient

Read more "Blog Post: Lazy Users Are Actually Efficient"

Blog Post: All Feedback Is Important

Make no mistake, when you are a serial entrepreneur trying to find the next billion dollar idea to be purchased by a large corporation, there’s a lot of knowledge in this blog post from Brett Berson of First Round Capital. You must be the true essence of agile to take an idea and slowly craft it into seed money.

For the rest of us, please feel free to take this article with a grain of salt.

Granted, I do not spend extended periods of time trying to find the next big thing. I am committed to providing value to the customers of Dealertrack Interactive and deliver well written guidelines of that value to my development teams.

That means getting feedback.

Some of the feedback comes from Google. Other aspects are from the business end of our company, as well as customers. In the end, the best feedback comes from a combination of all three.

I do not mean to degrade the value of this work. While the next big thing could be on the tip of my tongue, I have made quite a career of taking the ideas and thoughts of others and crafting them into a reality. Good product managers can also find hidden gems within their field with research and lots of time interviewing every single stakeholder.

Cherish the feedback you have the opportunity to receive. While not every idea has the same value, it is all on the road we travel. Sometimes, it takes a little work to reach the end.

Blog Post: All Feedback Is Important

Read more "Blog Post: All Feedback Is Important"

Blog Post: Work Estimates Stink…Sometimes

I love reading articles that question old business processes and point out the fallacy that at one point in time were shoved down our throats as “the way things are.” This article by Michael Dubakov at Target Process is one of my favorite because it involves one of the most cherished tenets of software design: work estimates.

Make no mistake, you have at one point in your career wasted a ton of time trying to figure out how long work you needed to do was going to take.

This applies to a ton of industries, not just IT. My father, who is an electrical contractor, uses estimates to know how much to charge for his services. He needs to accurately know how much his time is worth so that he can appropriately charge for it on an hourly basis when he hands a bill to customers. 

Same for developers, although in many medium-to-large-sized companies it is difficult for a developer to know this information. In reality, the financial worth of his or her time may not be valid because there are sales and accounting reps for that. What they do need, is an effective way to take a sprint and cut it into chunks so that work can properly be slotted into it.

In a sense, that is what your time is worth.

Now, as a product owner, it is my job to push the development team just enough to reach for a little more work than they would originally assign themselves. That is the tough challenge of a PO or Scrum Master. We must know when to push and when to lay off. 

This is where points comes into play.

With the advent of Agile methodologies, “pointing” a story became the new way to measure the work a team would try to accomplish in a sprint. Over time, this measurement is averaged to calculate the team’s velocity. Just how is this point measurement reached?

Scrum experts such as Mike Cohn recommends taking a list of tasks and assign numbers of the Fibonacci sequence (1…2…3…5…8…13…20…and so on) to come up with your own version of the scale. That way, tasks or stories can be measured for future work. That begs the question of how you know if you are making an informed decision or not.

Is that even possible?

Too informed of a decision means that we are falling back into the waterfall method. Too little of information involved with that decision — what’s the point of having process to begin with?

Measurement must happen in some form, because there’s no way to inspect and adapt if you don’t. The trick to this scenario is deciding as a team (and department if your company has several scrum teams doing work) what is important to making informed decisions.

I’m fortunate enough to work at a company that requires just enough. There are times when the heads of product and project management require more paperwork for work from me, but that’s what I’m paid for. The team shouldn’t have to worry about it, they have great work to put out for our customers.

To be successful, I need software that works. The product line is vast and the requests from our clients are even bigger. We have to get work done effectively, which means spending just enough of our time estimating. Then we can funnel our attention to the tasks at hand, then transparently measure our performance internally and improve.

So work estimates stink, but only when you have to spend more time estimating than necessary. To generate 100% accurate estimates, work become less important than the process. Agile means to use just enough of a framework to be successful and then get out of our own way. 

Working software, over excessive documentation.

Blog Post: Work Estimates Stink…Sometimes

Read more "Blog Post: Work Estimates Stink…Sometimes"

Blog Post: Determining #Product Value

One of the most fulfilling aspects of my job is the exchange of ideas. There are practical exchanges with my team, colleagues and customers that impact the work we do on a daily basis. Then there are the theoretical exchanges that happen online with other product people that either enforce or correct current mindsets I have about being the best that I can.

I think it’s important for anyone, regardless of your profession (including stay-at-home parents), to have those kinds of conversations. You can improve performance, discover new developments, and be encouraged to stay the course.

All of those reasons are why I enjoyed this read from Ken Norton, who is a former product manager at Google.

Reading the post reminded me that value is determined in a number of ways. Being so close to our product, it is easy to be blinded by the glaringly obvious. The feature or fix you thought previously so important could actually be of little value to the end user.

“Our wish list approach also created false equivalence. There was a huge chasm between what #1 meant to us and what it meant to our users. For us, it was first amongst equals. To them it was a painful tumor overdue for removal.”

What chasm am I missing in my road map between two features? Do I have something ranked inappropriately?

Often, I am presented with “quick win” ideas by business. In the development team room, this notion is sometimes scoffed at because it can seem like we are placating to the customer instead of telling them what is really important. What I think Mr. Norton posits is that in reality, regardless of however “quick” the “win” is, the request holds real value to the customer.

Sure, the possibility exists that the customer is asking for unnecessary items. Opinions can always be shaped. The important thing to remember is to weigh all of the opinions and make the best decision with the data you have.

Only then can you posit that your product has the highest value to most of the users.

Blog Post: Determining #Product Value

Read more "Blog Post: Determining #Product Value"

Blog Post: User Stories are Overrated?!?

Today’s link really got my blood boiling this morning, mainly because I have had Scrum training from Mike Cohn. I also hate it when people feel the need to go after the top people or businesses in an industry as a means of getting some notoriety. That may or may not be the case, nevertheless I watched the video from Tom Gilb seething.

After some Googling, I found out Gilb is a engineer and has made quite a career out of the inspection and metrics behind great software. I didn’t need to search to find this out, though, because that world view is clear from his approach to user stories.

That’s when it dawned on me that this video is a great teaching tool for product personnel. As I always say to my colleagues: user stories are the beginning of the conversation with development, not the end. The mistake I think Gilb makes is seeing stories by themselves as the sole piece of information an engineer needs to do complex work.

Having used this method of communicating requirements at several different companies, trying to lump all user stories in the same boat is hard. We all write them differently, and compile acceptance criteria differently. Within the same release, I am capable of providing a great amount of information that gives developers everything they need as well as the opposite. That’s where the conversation takes place.

Every engineer and architect I have spoken to have had their fair share of poorly written requirements. My favorite joke is to tell my team, “show me on the doll where the product owner touched you.” The challenge to my job is finding a way to meet them in the middle of the conversation and craft stories towards a method of delivering the best features possible.

So, instead of bashing Mr. Gilb for not reading and understanding Cohn’s methods, I would like to thank him for reminding me the purpose of my job. It’s not to stand in the way of great software, but making it easier and well thought out.

We involve stakeholders, help with design, converse with our teams, and document everything along the way. We are product managers, Tom, and our user stories can be your friends.

Blog Post: User Stories are Overrated?!?

Read more "Blog Post: User Stories are Overrated?!?"

Blog Post: What Can You Break?

I am always encouraged when writers can dig nuggets of truth out of other articles and interviews. What separates thought leaders from the rest is the ability to see what is just under the surface and apply it to their area of expertise. Such is the case with writer Kevin Ashton, and his Medium post on what made Steve Jobs great.

Of course, many have written about the former head of Cupertino and his genius. We didn’t need to be informed of that. Articles, books, and soon movies will be telling aspiring creators for years how awesome Jobs was. What I liked in particular about the post from Ashton was how a simple question can turn a good idea into great:

“Why doesn’t it work?”

Jobs was famous for asking this question about all products, including his. There is always something that can be refined to make something better. Often, this contradicts the stance companies have regarding their offerings that are “good enough.”

Not that they would ever admit that. They just don’t work on improving. My company was an industry leader several years ago, but that can only last for so long before competitors catch up and start to put pressure on you. While we still provide our customers an amazing suite of products, I am not talking out of school too much to admit we did not maintain our lead in some areas.

Catching up takes up a lot of energy. Regardless of the industry, most companies know what that feels like. Many who don’t have a mobile strategy in place should be feeling this strain right now.

When looking at your product line, don’t think of the things you like about it right now. That’s for the marketing department to discuss. Product people need to look at what’s wrong. Ashton’s equation of sales plus customers equaling nothing broken is really dangerous. You may have customers now, but your competitors are selling currently as well. Nothing being broken can turn into broke really fast. 

Instead of waiting for that to happen, look for something to break on your own. Perhaps your platform needs to be re-written, but to do that means breaking it down and slowly building that up. Instead of being upset, your customers will applaud your desire to improve their experience or more easily add features.

When you let someone else help you realize your product is broken, it takes more energy to catch up than if you do it on your own. Go find something and break it.

Blog Post: What Can You Break?

Read more "Blog Post: What Can You Break?"