1. What really makes a team agile?

   I hear and read a lot about the zen of agile, scrum, Kanban, etc. these days (actually for the past decade+). But I don’t buy in to the theory that time boxes, daily stand ups and sprint reviews make a team agile. What matters infinitely more is how we engineer software and release processes to shorten the feedback/response loop.

   Here are a few questions to test a team’s agility:

   How long after releasing code do you get user feedback?

   Do you generate and monitor real-time business and usage analytics for your product?

   How quickly can you respond to user and analytical feedback with product updates?

   Can you release whenever you want to?

   Is your testing automated?

   Frankly, it matters less what internal processes you use to drive the work the team does. I say whatever works for the team which is likely to include best practices from multiple methodologies.

   What matters more, and really makes teams agile, is an ability to ship and iterate quickly based on real user and market feedback.

   Code that’s checked into version control but not in the hands of users is like inventory sitting in a warehouse. Hidden costs abound. A tight feedback and response loop supported by strong engineering practices is the hallmark of a truly agile team.

   No Comments

   Categories: Agile, Product Development.

   By Jay

   — March 20, 2013 at 2:02 pm

2. Just ship it already

   As much as I advocate shipping to learn, I was called to the floor this week for not shipping a small product I’ve been working on. My initial reaction was indignant. But upon further reflection, I realized that all of the excuses I’ve been making for not shipping are just not good enough:

   • There isn’t enough functionality just yet
   • Usability isn’t perfect
   • The reports aren’t right
   • The business unit isn’t quite ready
   • There are manual deployment steps for the product
   • Etc…

   You know why they aren’t good enough excuses? Because each of these issues (for this particular product) will only take small amounts of effort to resolve. It’s when we treat the collection of small things as a big thing, “the product just isn’t ready,” that we lose sight of the opportunity cost of not shipping.

   I can respond to each bullet above with one question: what learning opportunities am I missing as a result of not being in the market right now.

   We don’t need the extra functionality to make an impact

   Usability will never be perfect, but we’ll never learn what it should be without real usage

   Those reports are the ones that the users really need

   The business unit is hungry for the opportunity this product will provide to improve margins

   Early adopters will deal with the manual deployment headaches

   Just ship it already. To ship is to choose.

   No Comments

   Categories: 100 words per day, Agile, Product Management.

   By Jay

   — February 7, 2013 at 4:04 pm

3. Start with less

   Users very rarely ask me to remove features from a product. In fact, I’ve never had that request… ever.

   This is why it’s important to show LESS in our prototypes. Whether discovering optimizations to an existing product or building a new one, we want to be guided by user expectations of what should happen next. Especially while we’re still searching for the right way to solve a problem.

   A minimum viable product (MVP) can be a flow chart, a sketch on paper, or even a high fidelity or live data prototype. Each of these is a tool meant to assert a solution to a problem as a hypothesis and elicit a discussion with a targeted user.

   By omitting seemingly key elements from the MVP we get to find out just how important they are to the user. Did they notice it was missing? Did they suggest something else?

   

   We can always add features later, but after we ship it’s much harder to pull them back. Sort of like trying to put toothpaste back into a tube. So, use the minimum viable approach, start with less, and you might find a leaner, more focused product when you’re done.

   Image credit: Bradley P. Johnson

    

   No Comments

   Categories: Agile, Product Discovery.

   By Jay

   — October 30, 2012 at 4:37 pm

4. Process for the Sake of Process

   I love the tenets of Agile, but process for the sake of process drives me crazy. The problem with “rules” and processes is that they becomes a crutch for B and C players to lean on when they don’t know what to do.

   It becomes permissible to inflate estimates for the sake of keeping burn down charts looking pretty. It becomes okay to sit in meetings talking about problems rather than working on solving them.

   I’ve been burned by both utter lack of process as well as too much rigor. Both suck, but process for process’s sake gives us permission to be mediocre rather than outstanding.

   The truth is that process is not the answer, it’s the people. ‘A’ players dig in and get stuff done and communicate along the way. Everyone else blindly follows the process. Agile is more than a process, it’s a state of being that starts with a burning desire to make an impact as opposed to simply checking boxes on a list somewhere.

    

   No Comments

   Categories: Agile, Culture.

   By Jay

   — September 4, 2012 at 3:47 pm

5. Be Less Efficient

   For well-understood problems with known solutions, it is often appropriate to optimize around job functions and roles. Think Henry Ford’s assembly line, the ultimate waterfall. Handoffs and transitions between individuals and teams can be executed with little fanfare as long as each follows a precise set of instructions.

   But when we develop software products, we’re often solving problems that are less well-understood and we should optimize around the discovery process in addition to the construction process. There are three roles that need representation during product discovery (1):

   • User Experience Design – Responsible for the usability and aesthetic of the product
   • Engineering – Responsible for feasibility and engineering direction
   • Product Ownership – Responsible for driving the value of the solution for customers

   Successful product teams have all three of these roles represented (2).

   Depending on the scale of the product, the three roles don’t have to be played by three different individuals. In today’s startups, these responsibilities are split in varying ways across two individuals. In some rare cases, all three are played by one person. Marco Arment, creator of Instapaper, comes to mind.

   Early on, it doesn’t really matter if these roles are played by 1, 2 or 3 different individuals (long term, it does) as long as usability, feasibility and value are all actively considered.

   What does all of this mean? It means that an engineer, a good one, may be spending a lot of time talking with users, not coding. It means that a product manager may spend a lot of time working to understand the benefits and tradeoffs of implementing a certain technology. An interaction designer might spend time helping groom the backlog to determine proper delivery order.

   In my experience, teams with members who allow the edges of their roles to be blurred produce results far superior to those whose members live neatly inside the box of a well-defined role. Does it impact engineering to have a top engineer engaged directly with users? Yes, absolutely. But the impacts are far greater when product managers and design throw projects over the wall to engineering.

   You can have the most efficient engineering team in the world and still deliver a product that users users hate and the market rejects.

   Everyone involved, engineers, product owners and user experience designers should make it their business to understand all facets of the problem and solution space. Your product and business will benefit from the diversity of views represented by the individuals who play these roles.

   ---

   
   1) I first learned of the core team (“triad”) concept from Marty Cagan‘s book, Inspired. Read this book if you’re interested in understanding what it really means to be a product owner who drives the product development process in your organization.
   
   2) A good example is Apple. Interaction Design – Jony Ive, Engineering – Bob Mansfield (hardware), Product Owner – Steve Jobs.

   No Comments

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

   By Jay

   — July 2, 2012 at 12:41 am

6. Learning by Rapid Iteration

   You can read 100′s of books, listen to countless podcasts and read documentation and blogs, but nothing replaces actual doing when learning to program. The repetitive nature of coding -> compiling -> running -> troubleshooting -> fixing and trying again seems to be the key for me in learning new programming languages and platforms. This is how I learned to develop apps for the web over a decade ago, and lucky for me what I learned toiling away in those days is still largely applicable today (i.e. the fundamental nature of how the Internet works has not changed).

   This learning paradigm works well for programming, but it can also apply to other disciplines. The key is to figure out how to iterate often, “debug” your failures and try again. In the same way that consistent weight training builds muscle tone, exercises of the mind have the same effect.

   My son joined the chess club at his school and has (at 6) mastered the mechanics of the game itself; which pieces can move in which directions and the general rules of play. Now he is learning the strategy. To assist his learning, I’ve given him the freedom to “take back” moves as a way to facilitate rapid learning. He makes his move, we play out the scenario together, then he has the option of trying something different once he understands consequences of the move.

   It’s the hands-on experience dealing with small failures that is so important in learning. The more rapidly we can physically see the consequences of our actions, the quicker we can adjust to compensate.

    

   1 Comment

   Categories: Agile, Productivity.

   By Jay

   — March 20, 2012 at 12:58 pm

7. Powered by Android: My “smart” fridge

   The future has arrived. Last week we accepted delivery of a Samsung RF4289HARS, Android-powered refrigerator replete with “built-in LCD screen, special apps, attractive design, large capacity and superior ice production and storage.”

   Finally, our fridge will better manage its energy consumption, let us know when we’re running low on staples, assist in managing the grocery list, and for fun, allows us to stream photos from our phones to the kitchen in real time. Okay.. not exactly.

   The RF4289HARS may be the best example I’ve seen of adding a product feature just because it’s possible. And I understand, being one of the first to market with a “smart-fridge” is important. But unfortunately, Samsung missed an opportunity to find out exactly what users want and bring true innovation to the market through a product that intuitively integrates with my day.

   I can’t add to my grocery list from the fridge and have the list available on my phone for those unplanned trips to the grocery store. I can’t remove the default photo album which contains stock photos of various foods. The slideshow of my kids is intermingled with random pictures of salads, eggs and pies. Twitter for the fridge is a stretch in general unless the fridge is tweeting vital info to me, “the door has been open for 10 minutes, close it!” But with no web browser to click through links, most tweets are useless. The list goes on and on, apps that were familiar from our smartphones have been purposefully and destructively scaled down.

   In reality, this would have a been a simple product to prototype, test, and iterate. Watching even a sophisticated user struggle to set up the photo album would have been eye opening. Does Samsung have the desire to innovate in this way or did they just need to check a box? “Shoehorn Android tablet device into latest fridge – check!” If they do have the desire, they may not have product development process agility enough to react and adjust to validated customer learning. What the newest breed of startups and enlightened established companies have learned is that user experience comes first and implementation details, i.e. the realities and possibilities of technology, follow.

   Our new refrigerator has a great industrial design and my wife loves it (most importantly). But I’m not willing to go as far as to call it “smart” just because it has an onboard computer.

   No Comments

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

   By Jay

   — February 20, 2012 at 1:17 pm

8. 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

9. 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

10. 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.