Winning with the Product

Ah the product. The thing people argue, worry, and sweat bullets to get out to somebody.  No matter what your app does, at some point, it must do it’s intended purpose for it’s higher power.  So, what does that look like when it’s going well or if it’s not.


  1. Consistent – The little things match the other little things. It has a uniform color, behavior, and UX pattern is understood and applied everywhere.
  2. It Works! – Without any technical oversight, the app is deployed, and able to be used, as is, by reasonable users without falling over or experiencing major issues.
  3. Answers the why – In the story the why ( or goal ) somebody wants to use your app is important, they want to do something. Can they now that they have your product?
  4. Iterate/Iterate/?? – Can the app change a part of itself without major surgery? All parts should be able to be changed and changed again if it means it’s a better fit or experience for the user
  5. Demo/Deploy easily – When it needs to be shown off to somebody, how easy is it? How often can we release code to the environments we have and how often/difficult is it to make it live?
  6. Performance – the app should perform as intended and without significant delay to execute the desired action.  Simple if it’s a website, more difficult if it’s processing something nightly.
  7. Clean Design – Ideally it would have been designed ( UX ) by a professional that understands good practices.  The app should do it’s intended purpose without much flare. Not every screen needs an ok button.

Bad – It’s too easy to say the opposite of all the good list, however true that is. In addition…

  1. Many Hands – If multiple teams/companies worked on it, can you tell? Did they use different technologies or techniques to put something out? Is it obvious?
  2. Usage – Are people using it as intended?  Metric/analytic programs help show you what the users are doing.  Is it easy to find that purchase button or do you lose users at a certain point?
  3. Documentation – Do they have to read a document or have a degree to understand how to do something? The answer should almost never be “Read the document”
  4. What was that? – Are there things that catch your eye or does anything happen once in a while? Random things are really annoying ( a recent example – scroll bars appearing or not )
  5. Loading..Loading.. – Do you click and wait, or do you go to look at a page only to see loading indicators spinning and spinning.  Ideally, there’s a performance tweak that could make them go away.
  6. Up Time – When you want to use it, demo, test, etc are you able to? Does one part of the app going wrong bring down the whole thing? Should it?
  7. Too Specific – Is it to limited by the environment or tech that was chosen? If the latest code has a major bug, how quickly can it be repaired. If someone leaves the team, would they take all the knowledge with them?

Ideally, as I’m looking at stories during a sprint, getting feedback on a demo or other customer call, the actions and issues are very focused on how to make the experience or task better. The more we are in discussions about issues preventing them from getting to that conversation, the more of an indication the product isn’t meeting their basic needs.

There is a great presentation from Gojko Adzic that includes the “Hierarchy of application needs”. 




I like to create things, work with interesting people, and do all things agile. I have a testing background and really want to make great products that solve problems.

Tagged with: , , ,
Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: