Product Triage
Want to make sure you ship a quality product that the entire team is behind? When the time comes, make sure you know when to get out of the way - or, help folks push in to a situation where you can get out of the way and they can get their feedback and ideas in.
Having been through multiple large release cycles, I know that there is a time in each where an element of urgency and awareness kicks in. Everyone pushes towards a date, but sometimes that date falls by the wayside in favor of shipping something that’s got a high degree of quality. This is a good thing so long as it’s monitored. Folks dive in and start firing off things that need to be fixed / debugged / better / etc…
This is a great time. But know your place as the product person. You have to get out of the way and let the triage happen. Development will be just fine managing the intake. They are just as close (and in some cases, closer) to the product as you are and you’ll find 9/10 they will make good prioritization decisions on their own.
All you can do is make sure you stay on top of everything coming through your inbox / noted at meetings / discussed on calls and ensure things stay as consistent as possible. That’s your primary job during triage, aside from doing testing yourself. However, that can sometimes be hard since you’ve probably been super close the product throughout the entire release cycle, so do your best and provide development with as much as you can.
The other thing to watch out for is to make sure triage does not last too long. You don’t want to be entering the third week fixing things like, “this word should be that world” or “change color X to color y.” People will get demoralized really quickly and start to feel like the team is pushing for an un-attainable level of perfection. Don’t fall in to this trap.
If you see this type of thing start to happen, push back and get the release out the door. Unless there are critical things that continue to crop up after a period of weeks past the initially estimated ship date (at which point, your development process may need to be evaluated if this is happening regularly), you are going 100% fine getting it out the door. If you are running iterations, remember - that “critical” word or color change can happen in 2-4 weeks time without a problem.
It’s of utmost importance the product gets released.
So remember - ship early, ship often. But get out of the way of triage. A team of people (especially management and others who aren’t as close to the product as you are on a day-to-day basis) will call things out you didn’t think of and you don’t want to stifle their feedback at all.
Just make sure you are doing your job during this process / stage of the lifecycle. Keep things consistent across the product as much as you can, and make sure this doesn’t turn into a multi-week exercise in perfectionism.
Happy shipping!
What Are Good Requirements?
What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK - it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands - but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each - they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work - for it to really work - you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way - I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths - it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release - or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation - and if it doesn’t turn out right, oh well - wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this - no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile - put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too - just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
Why Product Management Is Easy
I track the term ‘product management’ on Twitter. You can see the results of that search term by checking out a handy tool called Tweet Scan. Essentially, whenever someone mentions the words “Product” and “Management” in a tweet, I get alerted on my cell phone by way of SMS.
I’m a nerd, but I find it interesting. And, yes - this turned in to a hella long post.
Recently, and you should see this if you look at the search results, I’ve noticed a couple of folks talk about how hard a job product management is. I wanted to make some points here about this, and hopefully put to rest reservations folks may be having about exploring the possibility of getting into the job, or maybe even continuing doing the job if they are already in the thick of it.
My take is: it’s not hard.
Now, I’m not a product manager in a big, massive company. I never have been, and if I were a betting man, I’d say I never will be. That being said, I do in fact recognize that there are differences in how product management is done at say, Microsoft, and how I’ve structured it in the past. This is just due to the nature of the size of the organization where the job is sitting.
So, keep that in mind. My take on things is really related back to 20-50 (maybe 100 or less) person organizations. Anything upwards of 10,000 or 20,000 person companies really boggles my mind. So, hopefully that’s clear.
I do in fact recall when I was first put into the role. It was exciting, but at the same time, really ridiculous. Not for any other reason than, I wasn’t working for a more senior product manager to kinda guide me a long and instruct me on what to do - I was in there on my own learning as I went. It turns out, this is ideal for me, but I recognize it’s certainly not everyone’s cup of tea.
This leads me to admission number 1: The job is damn near impossible when you first start. Actually, scratch that — it’s damn near impossible when you get 3-4 months in. This is because, at least from my experience, it takes people about that length of time to really wrap their heads around what it is they are supposed to be doing. And I believe this is where most would sink and maybe start believing, “this job is WAY too hard for me, or anyone, to really do.”
And that’s 100% true. The way the job can be defined, it is impossible for someone to excel at. If you think about needing to be “proficient in Sales, Marketing (specifically, messaging and positioning), have a strong technical knowledge, excellent project management skills, well-versed in strategic alliances, and have a good foundation in finance.” Yeah. That’s a little tricky.
Let me take some of the surprise out of this description - there is no one that is “highly proficient” or “expert” in all of these things. They just don’t exist. You will either get a “tech” person, or a “sales” guy / gal, a “marketer” or a “project nerd.” But all of those wrapped into a single individual? Yeah. Not so much.
Now, this is where people may start to get down on things. How could you possibly do a job where all of those things are important? Some may say, “this is exactly what I think it’s HARD.” OK, well hold on - I’m getting to why it’s not.
Yes. those things are important. However, in a position like this, delegating is absolutely critical. That’s why you will usually see the line about “leading without authority” associated to many product management job descriptions. Why? Well, I’ll use myself as an example.
1. Am I a marketing genius? Hellz no.
2. Am I a great software programmer? Ummm, far from it. I may know a little LISP and SQL here and there.
3. Am I great with numbers? If you asked my grade 11 accounting teacher, she would say, “HAHA. No.”
And so on.
But here’s the key - if you understand *conceptually* how these things work, and maybe more importantly, how they work together, you are doing the right thing. No one person can build a great organization - it takes teams of people to do that. So, let’s re-visit those questions above with some modifications to them.
1. Do I understand marketing and have great marketing people to work with? Yes.
2. Can I give flexible requirements and wireframes to the outstanding developers and watch them develop wicked code? Yes.
3. Can I ask the finance people I work with to help me track project budgets to make sure I don’t go wildly out of control? Yes.
At the end of the day, so long as I understand the critical nature of cohesive positioning and building brand equity and help play air traffic controller to make sure marketing can do it’s thing, I’ve won. I can completely let go and push. IE, “I can give you feedback and my thoughts on positioning this product, but I need you to write the words and deliver something cohesive.” If they don’t, that’s another issue entirely. But I think you get the idea.
OK, so that’s a big long “admission # 1″ type thing. Once you cross that functional expertise hump, admission number 2 is this: The answers are right in front of you. Sure your opinion will factor a lot into the initial product release / development / design - but use those around you to vet ideas and build some momentum (no “i” in “team,” etc…). Someone actually has to DO things, but gather feedback (at least internally if you don’t have users yet, and then put something out in to the World.
Guess what? You are going to get a lot of stuff wrong. But it’s not about right and wrong. It’s about common sense and building cohesive products. The answers are always there - you just have to know where to look and how to ask.
So, is product management hard? No. The trick is not being the best marketer, accountant, UI designer, developer, Sales person all rolled in to one. The trick is to make sure that features get built, marketing communicates them, support can answer questions, and Sales can sell.
All the job is is connecting dots and knowing where to look for the data you need to make decisions. Don’t get overwhelmed by all the noise.
The Importance of QA
I am in the process of hunting for a great senior QA analyst. That being said, I wanted to take some time to talk about how important QA is in the product management process; or at least, how important I view it to be.
In my experience, if you are able to find and bring in the right QA person, that’s really into QA (and not just using it as a stepping stone), they will have a strong / noticeable impact on your product as early as its next release. I’m not kidding. I was lucky enough to work with a very talented QA engineer / analyst while at MusicIP, and his work ethic and results were absolutely perfect for helping us with several key initiatives.
So, what are some of the things that I’ll rely on QA for? I’m glad you asked…
Primarily, you don’t want defects in your product. I view the role of QA to help identify and manage bugs, but also prioritize them and ensure they are getting fixed. This way, I can stay focused on planning the product and trust that when a certain set of users can’t do something they are supposed to, it will get taken care of accordingly.
So, this means setting up your QA team to succeed. And usually, that means metrics and objectives. The key metric I’ll look to that’s directly tied to QA is product quality. Essentially, this is an amalgamation of high severity defects throughout the product (1s, 2s, and 3s usually). A great QA person will derive these priority values by assigning visibility and class rankings to them. For example, how likely is it a user will encounter a specific defect? And, if they do encounter it, what is the likelihood of it completely hindering their product experience?
You need to have these checks in place in order to ensure what you are shipping (especially as it grows and becomes more and more complex) is of the highest possible quality.
Now, the other key aspect I look for in QA is sanity checking my requirements and making sure their associated test plan runs the gamut. I may state that a user “must be able to create an account” and that “the username and password fields are required,” but the QA analyst will take this one step further and actually determine all of the permutations (that either may or may not be documented in the requirements) development must cover.
In this example specifically, maybe the e-mail address the user enters is malformed. Maybe their password doesn’t match to the 6-character standard. When you are working on releasing code quickly, especially in an agile system, this type of coverage becomes crucial. I need that constant stream of discussion and feedback.
Essentially, I’m looking for trust - not only from the product team, but the QA team (regardless of wether they sit in product or engineering), the development team, the marketing team, etc… I want to develop the trust that the QA team will catch critical user flaws (hopefully) before requirements even get to development for implementation so we can work out the kinks and ensure they are as clear as possible.
Beyond this, QA can really help development too — with structuring automated test suites, tracking their results per build and really grinding out the processes to ensure maximum build effectiveness (especially when using continuous integration tools) and insist the quality is really high and stays there. They may also be able to help when running core A/B tests on a site to help determine if user’s are encountering critical flaws in one implementation and/or another and what the outcomes are of possible change.
Remember, the “Q” in the abbreviation stands for quality. That’s their job. It’s not to administer servers or to be an authority for developers. However, it’s one of the most critical jobs in an organization - especially one that is just building / starting out. If the product you are releasing is poor quality, chances are it’s going to get very far.
Bring in an experienced QA person early and really maximize their value as much as possible. You won’t regret it, and your users will thank you for it.
Listening Labs
Not sure how many of you out there have been a part of usability studies or testing. My personal opinion is that “studies” put people in contrived situations and expect them to yield real-world data about how they are interacting with products.
This research is inherently faulty. Why? Namely because when asked, the natural response is for people to tell a researcher (or “expert”) what they think they want to hear.
Funny enough, Harry Beckwith covers this very, very well in his book The Invisible Touch.
I just watched one of Robert Scoble’s early interviews at his new FastCompany.tv gig with Mahalo founder Jason Calacanis. It’s not secret I’m a big Jason fan, and I think the Mahalo product is outstanding; in fact, it has replaced Google as my homepage.
The whole interview (parts 1 and 2) are really worth watching. However, about 13 minutes in to the first segment, they interview Mahalo’s Director of User Experience. He talks specifically about what i started this post discussing. His insights about what Mahalo does are fascinating - check it out:
To follow this up, Eric has created a Mahalo page with his insights and information about user testing. This is fascinating stuff, and I hope it can bring some additional depth to your product development process in the future.
