1. Writing Effective User Stories

   Writing Effective User Stories.

   No Comments

   Categories: Link Blog.

   By Jay

   — January 29, 2012 at 2:14 am

2. The Product is the Platform

   I was surprised to hear a colleague make the following comment a few weeks ago:

   We did the platform team a favor and designed our new feature so that it could be reused by other teams.

   My reaction was “Sweet! But… Aren’t we all building platforms?” If we’re not maybe we should be. My definition of “platform” is the collection of services, libraries and tools available to speed delivery of valuable product to users. By extension, the platform roadmap should be driven not by what is feasible and flashy from a technology perspective, but by what customers need and what gets product to the market fastest.

   In a now-famous rant by Steve Yegge of Google, he recollects his time at Amazon where Jeff Bezos’ mandated that all teams deliver their products as services which other teams could leverage through standardized API’s. This, in essence, helped transformed Amazon from being a very successful ecommerce company into a platform. Whatever the product, I would argue that it always makes sense to think about your product as a part of a larger ecosystem, even if the ecosystem only consists of other internal departments or business units.

   A few benefits of taking the platform mindset:

   • Compartmentalized ownership – A good product manager considers themselves the CEO of the product. By compartmentalizing your product, you ensure that control is maintained and that you can accurately monitor your application and its usage. Of course, as soon as you open the application up to the company, you are then responsible for its SLA’s and integrity as a service. But this is all part of true ownership and should be welcomed.
   • Leverage across product lines - Share functionality and data assets across multiple products. Reuse techniques have been around for decades, but we now have the luxury of open web standards and technologies which allow heterogeneous platforms to be more simply and reliably stitched together.
   • Future flexibility – By limiting the surface area of your applications through API’s future flexibility can be ensured because you know exactly how outside applications connecting to the service. Therefore you, can feel free to change underlying structure as long as the original service contracts remains intact.
   • Broadened reach – Platforms can increase the scalability of your product beyond the initial markets they were designed to serve. Niche product makers use API’s to build new solutions and can be a valuable source of new subscribers and licensees. Apps can be delivered to your users which would never be more than mirage on a long-term product roadmap. Resources are limited and you can’t build everything. Companies that enable an ecosystem of development have often have leverage against their competitors who believe they can build everything themselves, in house.

   You need look no further than Amazon Web Services which may already be a billion dollar business. Amazon exposed their massive online retail infrastructure to their internal teams as well as to outside developers and product shops across the globe to be leveraged by API’s on a pay-as-you-go basis. Whenever you are using a social media app, chances are good there’s an AWS service behind the scenes serving up portions of the request.

   There are costs associated with delivering your product as a platform, but doing so can multiply your product’s value. Let me be clear, there is no substitute for a compelling product, validated by customers, but, we live in a technology era where tools and creative engineers are ubiquitous. Providing thoughtful access to your data and functionality unlocks the potential of those assets to existing and potential customers.

   No Comments

   Categories: Agile, Platforms, Product Development, Product Management, Technology.

   By Jay

   — January 27, 2012 at 1:29 pm

3. Minimum Viable Product vs. Minimal Compliance

   

   Mike Holmes - Making it Right

   Mike Holmes has made a career out of fixing shoddy construction and renovations-gone-bad. On his HGTV show Holmes on Homes, he uncovers and resolves botched residential renovations and “just-enough-to-get-by” construction.

   Mike Holmes knows minimal compliance when he sees it – a level of completeness just adequate enough to fool unsuspecting homeowners into thinking their renovation project was a success.

   Does your product confuse minimal compliance with being minimally viable? It’s one of the easiest mistakes to make in terms determining the minimum usable feature set, especially when managing the precarious balance of resource, time and quality. Here are some common phrases that may indicate that you are working on a minimally compliant product or feature:

   “Integration can happen later”

   By choosing not to make critical parts of your system understand one another from the ground up, you are sacrificing your ability to ensure a great experience for the user. User experience is so much more than the way something looks – it’s how the user navigates between areas of the product and how their context follows them. It’s whether data is saved in the background so users don’t lose their work when the Internet connection goes down. And it’s in making sure that features aren’t just piled on but thoughtfully integrated into the product and connect with existing functionality in a way that’s not confusing.

   “It’s a training issue”

   This is an abdication of user experience to a team (usually) outside of Product. This may work for internally developed, corporate software, but products with heavy training requirements are harder to scale. Intuitive user workflows, graceful recovery from exceptions and general politeness and consideration of user goals in software products is good for business, primarily because it’s good for users. More product love, higher net promoter scores and fewer direct demands on linearly scalable resources such as training staff.

   “This feature is only used once in a while”

   Precisely why it should be user-discoverable and intuitive. The last thing I want is to make a user pull out a user guide, run a Google search or refer to a cheat sheet to relearn how to run a reoccurring monthly process.

   “Only advanced users will use this feature”

   Keep in mind that at any given time there will likely be a continuum of users from beginner to intermediate to advanced (Cooper: Inmates) who are using your products. Even the advanced users start out as beginners and intermediates.

   Marty Cagan defines MVP as simply the convergence of that which is valuable – people will pay good money for it; usable – it makes sense to end users; and feasible – it can be accomplished with the available resources. Given this definition, it is clear there is no escape from tradeoffs. But the design process gives us the chance to make the deliberately and thoughtfully. If you must sacrifice usability, why, and how will you make it up to your user?

   My company has adopted Cagan’s approach to product design. Here is are a few techniques we use to hone in on MVP during discovery and to deliver highly usable products:

   1. Customer discovery and prototyping – Not paper, not white boards, but real prototypes that users can touch and feel. Axure and Protoshare are two of several agile prototyping tools ont the market today. Of course, you can always use pure HTML to mock up prototypes as well. Giving designers a set of tools such as these to codify designs reduces the temptation to use prototype code as product code. More importantly it allows design to make significant progress on the product without draining engineering resources.
   2. Real user prototype testing – Find real users who can validate your ideas at your customer sites, in Starbucks, within your family and friends network, or wherever else you can. Develop tests that will quickly surface problems in the discoverability of your designs. Iterate fast and don’t stop until the interaction is well understood and highly rated by testing participants.
   3. Post-engineering usability testing – Prototyping is no substitute for usability testing in the engineered product. Take time to do this in line with sprints (if you’re an agile team). Fixing bugs before you ship is significantly less expensive than afterward, and if you take design seriously, usability problems will be considered bugs.

   All of these techniques are helpful aids, but in the end, relentless dedication to user experience on the part of the product team will determine a products fate once in the hands of users. This means design, engineering and product management working in harmony to craft solutions that keep users at the heart of whatever they choose to ship.

    

    

   No Comments

   Categories: Agile, Minimum Viable Product, Product Development, Product Management, Uncategorized.

   By Jay

   — January 20, 2012 at 8:09 pm

4. Personal Goals for 2012

   I tend to not set New Years resolutions unless I am really serious about achieving them. I have three kids, a demanding (yet rewarding) job, and extra-curricular commitments to tend to. At this point in my life, there’s little use taking on a new challenge unless I can figure out a way to go all in and achieve something significant.

   So here’s a list of the things I’ve chosen to go for in 2012. Much like a fundraising campaign I decided to start some of these things quietly toward the end of 2011 to make sure they were things that would hold my attention. In no particular order:

   Write.

   Publish at least one post per week on my blog (yes, this post will count!) and spend about 20 minutes each day writing. I have developed a nasty habit of starting posts that never get finished. In 2012 my standards for “definition of done” will be lowered. Instead of never being satisfied with an article, never completing research, and thus, never “shipping”, I’m going to take a minimally viable approach to my writing.

   Also, by making a commitment to writing a little each day I think I’ll be more consistent in honing my skill set as a writer. This will serve as both a personal conditioning exercise as well as a means to achieve the goal of publishing one article per week.

   Learn Piano.

   I have been musically inclined for most of my life, but have no formal training. I’ve played the guitar for 20 years, but am not much better today than I was 18 years ago. Piano has always been on my list to learn. My goal is to practice at least 30 minutes a day, five times per week and not break the chain. A more substantive goal will probably be added to this as well. For example, “perform three songs in front of an audience by X date..” For me, preparing to perform or teach drives me to new levels of proficiency both at work and at play.

   Run Half Marathon.

   I have run for fitness in the past, but a friend of mine asked me back in September to run a 15k (9.3 mi.) with him. Not knowing what I was getting myself into, I enthusiastically agreed and have been training for the race since. I tend to get shin splints when I run.. bad. In the past I’ve always quit when the pain got to me, but since I’ve set this as a goal, I’m going to go get some professional guidance on how to resolve the aches and pains for good.

   On New Years Eve day I ran seven miles which gave me a huge sense of accomplishment. Over the past few months I’ve come to enjoy running, and I also like that I’m more fit, weighing less and feeling more clear-headed since beginning a regular exercise routine.

   Vacation and Family Time.

   This year I’ll be more deliberate about taking time to relax with my wife and family. My company has a use it or lose it vacation policy (a good thing IMO). Over the past 6 years I’ve typically lost anywhere from two to five days of vacation. No more. We usually take several trips per year, but they are rarely planned well in advance. So, the goal is to take 2-3 mini-vacations with the family as well as an uber-vacation during the summer. This is the year that I’ll also start taking one on one road trips with my son.

   So, these are my personal goals. Ambitious yet achievable and well balanced with my professional goals. Now that I’ve written them down and shared them publicly I have little choice but to achieve them.

   No Comments

   Categories: Goal Setting, Minimum Viable Product, Personal.

   By Jay

   — January 13, 2012 at 8:20 am

5. Prioritizing Product Roadmaps

   Prioritizing a product backlog can be more of an art than a science. It doesn’t help that priorities can change over time given any number of arbitrary factors which is why it’s important to grab data points where you can about customer and market impact. Here are some questions I consider when prioritizing product backlog:

   • How many hours of implementation will be saved for customers and field services
   • Will it enable us to take an existing product down market (if this is part of the broader corporate strategy)?
   • How many additional customers will we be able to attract with the new capabilities?
   • How will the new capabilities allow us to compete more effectively
   • How many customers will benefit (the actual number), and in what ways?
   • Will it improve Net Promoter Scores, and specifically for which users?
   • Will it keeps us out of trouble with a client or group of clients
   • Was it previously promised to one or more customers (it does happen, but not the best way to prioritize!)?

   If you had to stand in front of your senior management team or shareholders and justify how you’re going to use the company’s precious engineering time, what information would you use? What other factors do you use to prioritize your backlog?

   No Comments

   Categories: Agile, Product Development, Product Management, Roadmaps.

   By Jay

   — January 6, 2012 at 6:48 pm

Proudly powered by WordPress and Carrington.