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.
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.
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:
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.
The French mathematician Blaise Pascal once wrote, “I would have written a shorter letter, but I did not have the time.” What Pascal meant was that it’s very easy to put everything and anything into a letter, but it takes time to refine its contents with the reader’s interests in mind.
The same can be said about building great products; complicating a product is easy, but simplifying it is hard and takes time. “Feature creep,” the tendency to add features just to add features, and “cart-horsing,” (mapping out your marketing plan before you even know what your final product is going to look like—putting the cart before the horse, in other words), are caused by breaking two of the most important rules for developing projects:
Research about customers, the market, and product usage (something you should always do) will help you understand what problem you are trying to solve. Without a problem to solve, it’s impossible to keep focused; you end up guessing, throwing every feature a customer has requested into your product, and wasting time and money on an overly complicated product that doesn’t actually solves real problems. Eventually you end up with something like The Homer, the ridiculous car-with-everything that Homer Simpson designed.
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?
The Hired Guns’ newest blogger, Matt Smith, is an expert at developing new products, innovative thinking, and startups. He’ll be putting his knowledge to good use for us as he writes about product management and methods to help companies innovate effectively, especially in an Agile environment. Matt sees his mission as “helping people grow, fostering ideas, and solving complicated problems in an innovative way.” We wanted to find out more . . . .
Hometown:
Newton, Mass.
Current ‘hood:
Upper West Side, NYC
College/Grad School:
Union College
Current Job:
Director, New Products & Innovation at Shutterstock
Where do you plan to take your column this year?
I really want to focus on success by innovation. Specifically how being Agile, in both product development and in business operations, can lead to innovation and, ultimately, success.
What do you hope to accomplish with your Hired Gun posts?
I’d like to help people understand innovation; how to find the open spaces within a business or industry, and fill them. Ultimately what we as product people are here to do is figure out how to help people, how to solve problems, and make people’s lives easier. At our core, we’re innovators. Or course, that’s much easier said than done.
Not everyone understands how to innovate, how to fill those gaps, and how to do it successfully. I’m writing these posts to help people learn and how to succeed.
Who should be checking you out?
Everyone from a new product person to a CEO who is looking to understand how to bring Agile to his or her business so that it can operate and innovate quickly and successfully.
There is a right way and a wrong way to be Agile, and it’s a slippery slope. When done the right way, Agile can help a company be incredibly successful, but when done wrong, it can really hurt a company. People who want to understand the right way to be innovative through Agile should be checking me out.
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.
Product Management, User Experience, Information Architecture, Interaction Design, Usability Testing
Project Management, Program Management, Production, Content Production
Animation, Art Direction, Creative Direction, Corporate Identity, Flash Design/Dev, Graphic Design, Web Design
Content Strategy, Editorial, Copywriting, Copy Editing, Research, Blog Outreach
Brand Management, Business Development, Sales, Product Marketing, Event/Conference Planning, Promotions, Marcomms, Corporate Comms, Direct Marketing, E-Marketing, Public Relations, Market Research
Account Management, Account/Brand Planning, Media Strategy, Communications Planning, Media Planning/Buying, Social Media, Search (SEM, SEO), Web Metrics & Analytics
Web Development, Front End Development
[no subcategories]
We have but one over-arching rule for comments: Do not add to the chaos of the universe.
