By Saeed Khan and Heather Searl
Parts 1 and 2 of this series covered a number of topics including working with other teams, organizational structures, personas and common documents. This part delves into:
Agile and Documentation
Heather: Agile presents a lot of problems when working with development. I worked for a company that moved to an agile development methodology, but sold into a very regulated market. As part of the move to agile a lot of formal documentation was reduced and omitted.
That didn’t work for the customers who needed to see a clear process and documentation on changes from release to release for their own regulations.
So we ended up developing the product using an agile methodology but on the side we’d sit through long meetings creating requirements and arguing over whether the wording for each requirement was “should,” “shall,” “must” or “may” on things that were half built already
Saeed: That’s just bizarre. You mentioned Agile. I’ve had a lot of trouble with Agile and Product Management, but we don’t need to get into all of that here.
There is definitely good in the Agile process but people don’t pay attention to the basics. One of the principles of the Agile Manifesto is “working software over comprehensive documentation”.
People think “Hey, I don’t have to create documentation. I can just build stuff.”, and they run with that idea because it is what they want to do.
If they just read and understood the basics, they’d realize the principles are structured as X over Y not X instead of Y. i.e. focus on the first, but don’t ignore the second.
Heather: I then went to a start-up environment where I asked to see specs and documentation on an existing product so I could understand everything it did to start working on the next iteration. There was no documentation.
I was told to just try using the product and figure it out that way. As you can imagine that created a ton of issues for next generation products. Developers would agree to something and then discover the existing code didn’t work the way they thought and timelines would have to change.
I was told that I should create the spec documentation based on trying to use the released product. We actually tried to do that a few times and we tried to create a site map for a complex web app but gave up because there were so many different paths that we kept missing things.
All projects at that company had to have multiple long term employees on the team or all hell would break loose. New developers, a new product manager and new UX person on a team and a project would be defined, scoped and agreed upon that was totally impossible because of legacy code, designs etc.
Saeed: Any process where people think a written record of the product can be done away with to save time and money, is doomed to fail. It’s truly penny-wise and pound-foolish.
As you said, new teams couldn’t succeed because all the required knowledge. How well could a mechanic repair an engine of a new car without any manuals or diagnostics?
I always find that documents helps. I write a lot of documents. I will write a Word document instead of using PowerPoint because sometimes the detail is really necessary. It also helps me get my thoughts organized and can be a reference document later as our collective memories eventually fail.
Also, it is easy to distill a Word doc down to PowerPoint, but not the other way around.
But unfortunately, many people don’t know how to create good reusable documents, so it creates a huge gap very early in the design and development process.
Ownership and Decision-Making
Saeed: One interview question that I ask product managers is how would you describe product management in one word. There is no right answer but there are bad and good answers. One of the answers I would give if asked is “balance”.
In the end product management is about balance. Sometimes I need to focus on the technical, other times on the financial but over time this has to balance.
Heather: The word that was coming to mind is compromise. Thinking along the lines of what you said for balance. But balance is a better word. Compromise has too many negative connotations of giving in or creating mediocrity.
I like to think of myself as a product management’s right hand person – or one of them. There are a lot of other groups providing product management with key input. I want to be listened to, but I get to dump the hard decisions on the product management who has to decide between the best user experience the scheduled the budget, competitive pressures etc.
I don’t have to be balanced. I get to stay focused on a single idea – what is best for the user. I get to argue for that and someone else makes the hard calls.
I like that I get to dump that on you. In the end I can argue my position and someone else has to balance it all.
Saeed: I don’t like the word compromise because of the negative connotations. Compromise sounds weak.
It is very clear when you see a failed product that there was no balance. There may have been a lot of compromise but no balance.
For example, the marketing may be great, the visuals fantastic but the technology platform is weak and makes the product weak overall. Or vice versa.
I prefer to get a good product out there and worry about the marketing later. But other people come at it from the opposite point of view. Go out with a bang.
Heather and Saeed
Tweet this: He Said, She Said: Part 3 – How can Product Management and UX work together http://wp.me/pXBON-4di #prodmgmt #ux