M.JORDON SMITH | WRITINGS

Originally posted on The Hired Guns

As product people who subscribe to a lean and agile methodology, we have a tendency to think in short bursts and only focus on the near term, because after all, things change.  Our typical strategizing looks like this:

1. Determine key priorities for the quarter
2. Determine metrics for those priorities; i.e. when we complete the priority, how will we know if we are successful or not, did we move the business forward?
3. Focus on priority 1 until it’s complete, and then move on to priority 2
4.  Always be willing to adjust based on user feedback and product discovery (testing ideas, seeing what works, and failing fast to move on to the next idea)

However, the downside of this type of thinking is that you can lose sight of the bigger vision and of the long-term business goals.

In order make sure that we don’t lose track of the bigger vision and make sure that our quarter to quarter priorities help move the business forward in the right, I am proposing that we instate a “Look-back” at the start of every year, and check in with it in June to see how we are doing.  Here is how it works:

1. Start the year by thinking about the end of the year

Instead of saying, “What are we going to do this quarter”, start the conversation by saying, “What do we want to have accomplished by the end of the year”.  From there you dive into a quarter, and ask yourself, “What can we do this quarter to get us to that December goal.”  This is how you should pick your priorities for the quarter.

2. Make sure the conversation is around accomplishments and metrics, not features

 Focus on how the business moves forward, not on what features you deliver.  The end of the year conversation should be something like, “We introduced a new product line that doubled sales.  We increased 7-day retention by 12%.  We increased ‘adds to carts’ by 15%.”

3. Stay focused, be willing to adjust

This is where we get into our standard strategy process.  If the goals and metrics you set forth in step 1 and 2 are still in play, use the agile and lean methodologies to figure out how to achieve them.  Fail fast, adjust, test ideas, get user feedback, and push forward until you hit those metrics.  Check-in with yourself and question if your year-end goals are still the right ones.  It’s ok to adjust your end of year goals and metrics.  Remember, our ultimate goal as great product people, is to provide value to our users and move the business forward.

In conclusion: 

This Look-back is about what we want to accomplish by the end of the year, it’s a tool to help us think about strategy and how we can achieve it.  Anything you build in Q4 wont affect the bottom line until the following year, and Q3 tends to have minimal impact on a year.  So to really move the needle, you need to attack in Q1 and Q2, refine in Q3, and adjust and plan in Q4 for the following year.  Great products start with great strategy and can only be born with great product discovery.

Originally Posted on The Hired Guns 

Great product people understand their users in a qualitative way — what their motivations are, what they use your product for, and what issues they have with your product. It’s a core part of being a product owner, particularly when you are looking to build something new. But when you are looking to optimize your site experience, you also need product metrics.

Qualitative research tells you “why,” but product metrics tell you “what.” It’s metrics that help product owners make decisions and, even more important, understand if those decisions were ultimately right or wrong.

Let’s say that you are looking to optimize your search experience, and one of the items in question is your advanced search: should you hide it or or do you make it more prominent?

Sitting with a handful of folks to talk about how they use your advanced search is great, but you need to keep two things in mind:

1. If all the customers that you speak with say they love your advanced search, chances are that you are on to something, but you must remember that they are a small sample of your users. Metrics let you know if these customers are a true representation of your total user base.
2. People tend to say one thing and do something else. Users may tell you that they love your advanced search options, but in reality they never actually use it. Metrics will let you know how they really use your site.

Ultimately you are using customer research and product metrics to make a decision. Let’s say that after you talk with a few folks, you learn that they don’t really use your advanced search, and then you look at the overall usage metrics, and it turns out that only 50% use it on a daily basis. Perhaps you decide to hide advanced search and only have it appear when users click on a button.

You may have assumed that this was the case before you started talking to folks and looked at the metrics, but by making a decision based on research, you have mitigated the risk of just going with your gut or just talking to one or two people.

After you make a decision, it’s also important to monitor the site and see if you made the right decision. For instance, if you hide advanced search, does search success go up or down, does repeat usage go up or down, do new user conversions go up or down, does the time on site go up or down?

Just as much as you need metrics to make a decision about hiding a feature, or changing how something works, you need to have tracking in place to understand what the outcome is, to understand if you are successful or not — in other words, whether or not you made the right call.

In order to know what metrics you should be tracking, answer the following questions before you make a change:

• What problem are we trying to solve?
• How do people use this page, feature, etc., right now?
• What are the primary metrics we are trying to improve? (For instance, we want to increase search success by 2%.)
• What are the primary metrics today? (E.g., search success today is 25%.)
• What are the secondary metrics that we want to make sure that we do not adversely affect? (We want to increase search success, but we don’t want to decrease new customer acquisition while we do it.)

This sounds like a lot for a product person to keep in mind, but there are ways to manage this:

Dashboards. Have your key metrics on a big screen so that everyone on your team can see them. When you make a change to your site, you can all see if something changes.
It’s not just about you. Your team, developers, designers, etc. should feel just as much ownership over these metrics as you do. The more eyeballs you have looking at these metrics, the better off you and your team will be. In the end, your customers will benefit.

In a previous post, I wrote about making sure you focus on priorities over deadlines, and one of the main ways you do this is with metrics. Make sure that everyone in your business is aware of them, and make sure they know that you pay attention to them. Metrics help you mitigate the risk of your decisions and to track their success or failure.

Here’s an obvious statement: the web (internet, computers, mobile, all of it) is changing. Here’s maybe a less obvious statement, but still nothing groundbreaking: the rules for how you build, maintain, and grow business on the web are also changing. This means that you need to adapt, to be prepared to change how you operate, and to be different from what you are today. What works today is almost certainly not going to work tomorrow.

If you plan on being a successful product person in the next few years, then in addition to thinking about what the product is, you are going to have to think about user experience, about business metrics, about marketing your product. In addition, you are going to have to do it while building products in an Agile fashion, so that you can fail fast, learn, adapt, and build the best business you can. I’m calling this change the Rule of PLUMB. PLUMB stands for Priorities, Lean, User experience, Marketing, and Business. Before I get into my thinking, let’s look at the past to see where we are headed (and why).

Product People Today:

There are two types of product people today, the pinballers and the visionaries.

Pinballers serve as a translator between development and executives; their job is to take directives from someone higher up, make sure that the product team follows them, and then communicate that progress back up the chain of command. Pinballers tend to be found in large companies, where there’s lots of middle management. They have a very tactical approach to their job.

Visionaries determine the direction and the priorities for the product; their job is to research and to be very far out in front of the team so that they can understand where the business needs to be. Visionaries tend to be found at startups and smaller companies. These are very strategic roles.
Pinballing tends to not work that well these days. With that setup, where you have management telling product people what to do, many details get lost in translation; the people making decisions are not talking with developers, are not talking with designers, and most important, are not talking with customers.

The right way to run a product organization is with visionary product owners, who can be strategic and assess the needs of the business from a product perspective. The best environment is one in which there is an open line of communication between developers and customers and product owners and executives.  Everyone should be on the same page, and product owners should be leading the charge, with both qualitative and quantitative data to back up their plans.

Visionary product owners focus on creating a vision and then making parts of that vision a reality, so that they can test and validate it as they go. This is how you build great products today.

Product Owners of Tomorrow:

So where are product owners headed? What methods will be successful in the next few years? As much as product owners should strive to be visionaries today, if they want to continue to be successful in the future, they need to be able to think and act like user experience designers and general managers.

How can you make the best decisions about your product if you don’t understand how an interaction works or the business implications of your decisions (i.e. how will this affect SEO, how will this affect Average-Order-Value?).

This is where my idea of PLUMB comes in.  Product owners need to expand their concern to include the following:

1. Priorities: Talk to customers, do research, determine what is the first priority, and focus on that.
2. Lean: Be Lean with how you attack priority number one. Get something to customers fast and then iterate, using Agile methods.
3. User experience: User experience is how people interact with your company. And UX is king — it becomes your brand.
4. Marketing:  Understand how you will get the word out. You should know how to talk about your product or the changes that are made, or be able to respond to questions about it. How will you announce changes on your site, and how will you make bigger announcements?  Work with marketing on issues like this so that everyone understands what’s in store.
5. Business: Understand the economics of your product; what sort of revenue are your bringing in, and how? What factors determine how much customers make use of it?

Focusing on the five aspects of PLUMB means that to some degree that product owners are taking on some responsibilities that are closer to those of a UX designer or general manager. I don’t necessarily think that the three distinct roles will all blend together in the future, but it does mean that all three will have to think much more about same things — the big picture. PLUMB is one way to help make that happen.

Originally Posted on The Hired Guns

One major misconception about Agile product development is that there’s no long-term planning, and that everyone just does that they think should be done in the moment.

This couldn’t be further from the truth. Successful Agile shops are ones that put a strong focus on strategy and know exactly where they want to go. Being Agile means that you outline your high-level business goals first, that you think about the six-month and twelve-month plan, that you focus on problems over solutions, and, ultimately, that you abandon timelines and allow yourself to adjust priorities as you go.

Unfortunately, this is where most executives struggle; “How can you not have a timeline? When will things get done? How will we plan?” It’s understandable that executives want to know how time and money is being spent, and timelines and Gantt charts have their place in certain kinds of businesses: see my previous post on Waterfall vs. Agile approaches. But in the world of web development, timelines equal compromise, and compromise equals failure. When you commit to the dates on a timeline, you might as well let everyone know right off the bat that you will either miss the date, or that you will compromise the product to hit the date.

But what’s the right way to do long-term planning in an Agile environment so that executives (and everyone else) feel comfortable with the plan? The answer is a road map based not on deadlines and wants, but on priorities and needs.

In Agile, you should always focus on the problems you’re working on solving. This helps you get rid of the things that you may want but don’t really need. This is about focus. A project’s “needs” should be broken down into two categories:

• Rocks: The big things, including overarching directional products — things that have to be broken down into smaller tasks and things that will take weeks to accomplish.
• Sand: The small things: product and design tweaks, tech debt, etc.

Once you know what you should be focused on, then you have to prioritize, while knowing that at any point priorities can change. There are no deadlines here.

Then it’s about conversation — there should never be surprises. Get commitments early and make sure people know what you are thinking for the short term and the long term. For instance, “We know we want to focus on advanced search first, so that’s what we are going to do. After that, we want to focus on our sign-up process, followed by a new home page, but that could change.”

Your goal as a product person is to make sure that “priority 1″ really is the right thing to be focused on. Once we know what priority 1 is, we focus on that until we are satisfied that objectives have been met. Everything past priority 1 is subject to change as time goes on, and that’s OK — that’s the point! You can’t put a date on something that you aren’t working on, something that the team hasn’t sunk their teeth into yet. And you shouldn’t have to. Staying true to Agile development means maintaining focus, doing lots of quick releases, taking into account customer feedback, and performing lots of iterations. Because you’re incorporating feedback, what you end up creating is likely to be vastly different from what you thought you were going to be doing on day one. Again, that’s OK; that’s the point!

When you are done with number 1, you can move on to priority 2, or adjust your priorities based on research you were doing while working on priority 1.

And let’s not forget about the “sand.” That gets prioritized just like rocks do — on a need vs. want basis. Every now and then you find that a developer has some free time: enter the sand. Pick off the little things when you can, as long as they are the most important little things and they don’t distract from the larger effort required for rock “number 1.”

Things change, priorities change, what we do changes, and as long as we have a plan and so long as we know that the plan is subject to change, we are in a good spot to talk about priorities. Healthy conversation, getting people on board, and understanding the process outlined above is the right plan of attack.

Remember, as a product person, you need to know where you want to be in six to twelve months to understand how to get there (see my previous post on the 80/20 rule). The better you know where you want to be, the easier it is for you to communicate your vision with management. And the easier it is for you to communicate your vision and execute it, then the more management will be at ease without deadlines, timelines, Gantt charts, etc.

Being Agile is about more than just developers, product people, and designers being OK with adjusting priorities. It’s also about management being OK with these changes, and your job as a product person is to lead the way.

Originally posted on www.thehiredguns.com

One of the keys to success for a great product person is having control of your backlog; i.e. knowing where you want your product to go in the next one, three, or six months. Agile software development doesn’t mean that you don’t have a solid plan for your product, it means that you’re flexible on how you get there.

For example, I live in New York, but grew up in Boston and often visit to see my family. There are several ways I could get there:

• I could walk (not the quickest solution, but it’s possible)
• I could take a bus (lots of stops, but better than walking)
• I could drive (faster than walking or a bus, but more expensive)
• I could take a train (fast, allows me to do work, but costs more than the previous options)
• or I could fly (the fastest, but getting to and from an airport and through security is a hassle)

At the end of the day I’m going to get to Boston, I just need to figure out what factors are most important to me: time, cost, or convenience. If cost were really the most important factor, then maybe I’d walk. If cost is just very important, then maybe I’d take a bus. If time is the most important factor, I will probably fly, but if it’s a combination of time and convenience, I will most likely take a train.

Deciding on your objectives first will determine how you accomplish the day-to-day steps that take you toward those goals. In other words, your objectives determine what your backlog looks like, which ultimately leads to success.

For those that are new to Agile, your backlog is a list of prioritized “user stories” that your team will work on. User stories should always reflect the following; 1) the group the story represents, 2) what is being done for that group, and 3) the value that the story will bring. For instance, “1) As a traveler, 2) I want to go from New York to Boston in the quickest possible manner that doesn’t inconvenience me or cost too much, 3) so that I can visit my family.” When you have all your user stories in place, your backlog will be in order and it will reflect your objective and your goals.

In order to be successful, you need to know where you want your product to be in the short, near, and long term.

To help with this, and to make my life easier, I like to practice the 80/20 rule.

The 80/20 Rule

The 80/20 rule is pretty basic. As a product person in an Agile world, you should spent about 80% of your time focused on the long term and 20% of your time focused on the short term.

The 80% is taken up with thinking about where you want your product to be in three to six months.  You should focus on:

• What problem(s) are we solving for and what is the value to the user? (It shouldn’t be a list of features, it should be a list of the ways you’re helping the user.)
• How does this fit into the bigger picture? (That is, making sure that your product fits into the user experience and your overall business.)

The 20% should be spent making sure that your team is focused on the current sprint, and that you have the next sprint pretty much locked in place. You should focus on:

• Does the team understand the product plan? (In other words, the value that it’s providing to the user.)
• How are we going to solve the problems? (How are we going to deliver that value?)

Without understanding the 80%, your 20% becomes incredibly “noisy” and distracting; your team will lose focus, your product will suffer, and you will end up with ad hoc, quilt-like software (a whole bunch of little things that are stitched together to make something inconsistent and random). The more research you do and the more you understand your users, the easier it will be for you to recognize the problems you should solve.

The more you understand the 80%, the easier the 20% becomes. Focusing on the 80% creates a higher “signal-to-noise” ratio and will lead to a more successful product.

Originally posted on www.thehiredguns.com

People love buzzwords—they help make you part of the conversation. Unfortunately, they can also make you look foolish if you really don’t know what you’re talking about.

When it comes to software development, Agile has become one of those words. In the last eight months, I have interviewed over a hundred product managers, directors, and others. All of them threw “Agile” out there as a part of the conversation: “Oh yeah, we’re an Agile shop, we gave up Waterfall years ago.”

Here’s the problem with that sentence, specifically the word Agile: everyone has his or her own definition of what it means. Agile has generally been a software development word, a repositioning of development away from Waterfall. But it’s also much more than that.

To understand Agile a bit more, let’s step back and understand what Waterfall software development is and where it came from. Waterfall is based on the idea of having requirements upfront, getting design and implementation after the requirements, and doing verification and maintenance at the end. This method was a carryover from manufacturing and construction, where everything had to be very well thought out and planned ahead of time, because even the slightest change would be hugely expensive.

In these situations, the notion of a Waterfall approach makes perfect sense. If you’re going to build a bridge, you better not start without knowing where the bridge is going to connect on the other end, and you better have a huge amount of specifications for everything. But for software development, where things move quickly, and the cost of adjustments are minimal, this type of development just doesn’t make sense.

That’s where Agile comes in. Instead of planning everything out in advance, Agile favors lots of small incremental decisions, and it can also adapt to changes throughout the process. There are lots of flavors of Agile out there: there’s scrum Agile, non-scrum Agile, kanban Agile, and hundreds of others. Then there’s the kind that unfortunately tends to be the one I hear described most often when people talk to me about Agile. It’s fake Agile.

Fake Agile is just that, it’s fake, it’s not even close to what Agile is meant to be. Fake Agile is a company’s attempt to mask Waterfall software development.

In any kind of Agile, the massive specs that Waterfall requires are replaced with “user stories.” But in fake Agile, the product owner has to spend a massive amount of time making sure that upper management signs off on the user stories, and also that the user stories have “acceptance criteria.” (For instance, we will build a house, and the house should have four windows and each window should open and close, and the house will have a door, with a doorknob, that opens from the inside out, and the lock should be double bolted.) Oh, and each user story must have a “time to completion” so that upper management knows when everything will be finished.

If you just read the above and said, “yup, that’s how we do Agile,” then I’m sorry to be the bearer of bad news, but you are surrounded by fake Agile, and you’re really in a Waterfall shop.

A fake Agile environment is tragic (and I speak from experience). It’s destined to fail: no one can know all of the aspects of a product (design, usability, functionality, and value) before any work has begun. Most important, it removes the ongoing conversation between developers, product owners, and the most important person in the process: THE USER.

Agile is not just another buzzword, and it’s not just about software development. Agile is about conversation, it’s about feedback, it’s about adjustments, and ultimately, and most important, it’s about innovation. The best products I ever built were built by making sure that I had the right people as part of the process. As the product owner, you are responsible for the value of the product, but you cannot bring a product to life with having a developer to make sure the product is feasible and a designer to make sure the product is usable. The three of you should be focused on thinking about how a product might work and getting something in front of users as soon as possible to get their feedback.

Being Agile and building great products is about making sure that you have four perspectives always accounted for; value, feasibility, usability, and demand (in other words, do users want it). Conversation, feedback, adjustments, and innovation are how you will be able to build a successful product, impress upper management, and succeed as a product owner.

This level of understanding of Agile has been so successful that more and more companies are starting to speak about Agile as more than just software development; they view it as a way of running a business. Companies understand that having a one- or two-year roadmap only works if you are willing to be flexible in what it is you are looking to accomplish. You may want to focus on internationalization in Q4, but halfway through the year you realize that there is a larger opportunity to continue to expand domestically. Being able to make this change midstream is fundamental for success, and failing to make this adjustment could be a huge mistake for the company.

Planning is good, knowing where you want to be is better, but being able to adjust along the way is the best.

Originally posted on www.thehiredguns.com

It may sound funny, but the best product people are the ones you rarely see. Being a great product person means that you understand your own business, the competitive landscape, and current market trends, but most importantly, it means you understand your users.

Everyone has opinions, and opinions can be good, but they can also be dangerous. The biggest trap for product people is to have an opinion on day one—whether “day one” means it’s a new product or that you’re new to the position or new to the company.

Opinions based on nothing but your gut are just assumptions. If you make statements like “This is how people are going to use our product” and “I know what people are looking for, so let’s build that,” and you only have your opinion to back them up, than what you’re really saying is, “This is how I assume people are going to use our product” and “I think I know what people are looking for, so let’s build that.” When you do this, you’re guessing, and guessing leads to failure.

What you should be doing is getting out of the office and talking to your users (either current or potential). Opinions and assumptions are good, but then you have to get out and talk to people. Ask users how they do their job, what frustrates them, and what would improve it. These conversations should be made before and (even more important) during development. As you build, bring prototypes to the users and expand the conversation by asking them to use the prototypes. Ask them what they like and don’t like about them. Does it solve a problem for them? Does it make their life easier?

At least half of a product person’s time should be research: market research, competitive research, and user research. User conversations will strengthen your opinions about what your users are looking for, and you will go from assuming what to build to knowing what to build.

If you want to succeed as a product person, you should expect colleagues to say “I haven’t seen you in a while, what have you been doing?” As long as you’ve been spending most of your time with customers in order to understand what they need and what problems you’re going to help solve, then you’re on the right track. You need to be able to tell your boss or senior management that you know exactly what your users are looking for, and you need to be able to back that up with solid research: surveys (both qualitative and quantitative), analytics (usage, both transactional and non-transactional), and feedback from user conversations.

Being a good product person is about having strong opinions, but also about mitigating the risk of those opinions. Instead of just making decisions based on your gut, support them by doing research, by understanding usage and numbers, and (most important) getting user feedback.

Everyone has a boss; whether it’s the director of product (assuming you are a PO), or the CEO (assuming you are the director of product), or the board (assuming you are the CEO), and we all have to be able to explain what we are doing and when we plan on doing it.

In most cases people above you expect timelines.

“What are you doing and when will it be done.”

The idea behind the question is OK, i.e. I want to know what’s going on, but the issue arises when they expect actual dates.  This is the timeline-trap.

If you buy into the idea of timelines, all you are doing is setting yourself up for failure and an angry conversation with your boss.  Yes, it’s true that you can hit certain dates, but chances are, that more often than not you will miss a date for one of a hundred reasons; all very reasonable reasons too.  But, your boss wont care about the why, all they will care about is the fact that you missed a deadline.
Avoid The Timeline-Trap

Instead of timelines, we suggest roadmaps.  The main differences between a timeline and a roadmap are:

1. Priorities versus deadlines
2. Needs versus wants

When we look to prioritize the needs versus wants, we like to break things down into two categories:

1. Rocks: The big things, overarching directional products
2. Sand: The small things, product tweeks, tech debt, design tweeks

Once you have need over want, make sure that the number one thing you need is at the top, the number two thing you need is second, and so forth.
Communicate The Plan

Now it’s about conversation – you should always set expectations accordingly, and make sure everyone is on the same page.  Get buy-in.  ”We know that we want to focus on Advanced Search first, so that’s what we are going to do.  After that we think we want to focus on our signup process, but that could change.”

Everything past the number one item is subject to change as time goes on, and that’s ok.  Being agile is not just about software development and two week sprints and having releasable code at the end of the sprint.  It’s about a business mentality that starts at the top and trickles down to everyone.

Once we know what our number one thing is, we focus on that until we are satisfied that our goals/objectives have been met. We don’t know how long that will take because we don’t know exactly what we will be doing, until we kick things off.  Staying true to agile development means focus, quick releases, customer feedback, and iterating.  Based on feedback what you end up creating is most likely going to be vastly different from what you thought you were going to be doing on day 1.  And again, that’s ok; that’s the point.

When you are done with number one, you can move on to your number two or adjust your plan based on what took place during working on thing number one.

And let’s not forget about the sand.  The sand get’s prioritized just like rocks -  based on a need vs. want process.  Every now and then you find that a developer has some free time; enter the sand.  Pick off the little things when you can, so long as they are the number one little thing and don’t distract the larger effort of the number one rock.

Visualize

Below is a Visual Product Roadmap; a template that we use to help us communicate effectively to our board members.  You will notice that once you get past Q1 everything starts to fade.  We want to visually show that we are committed to thing number 1 and less certain about things (rocks and sand) past Q1.

Things change, priorities change, what we do changes, and so long as we have a plan and so long as we know that the plan is subject to change, we are in a good spot to have a healthy conversation about prioritizing.  Healthy conversation, getting people on board, and understanding the process outlined above is a good plan of attack.