Skip to content

  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.

    Categories: Agile, Product Development.

  2. Everyone interacts with users

    I just spent two days with 45 users representing 17 customers along with several colleagues including some of my engineering team, and I was reminded that when engineers interact with users, fantastic things happen. Problems are understood deeply, clearly, and solutions are conceived.

    When software companies get big, employees are organized by function. While necessary on one hand we do a terrible disservice to users when divide responsibilities. For instance, product managers are responsible for understanding the user problems they want to solve, designers are responsible for prototyping solutions, and engineers are responsible for crafting the final product.

    In this process, there are multiple handoffs resulting in lost fidelity as we transition from problem definition to solution. Wouldn’t it be better if the engineer, designer and product manager were interacting with the user firsthand?

    In my experience, some of the best design insights come from engineers, value definition is clarified by clear-thinking designers, and product managers can drive key technical decisions. In a traditional organization with rigid role definitions, these occurrences would not be possible. Everyone looses, especially users.

    So my thesis is this: If everyone in your org is interacting directly with customers in some way, my guess you are building better products faster. If not you’re losing productivity and innovation opportunities that can be gained by applying the best and brightest minds in the building directly to customer problems

    Update: Case in point, Just ran across this article on British Airways launching a program to put tech staff on flights with customers.

    Categories: 100 words per day, Design, Product Development, Product Discovery.

  3. Organizing platform development

    Dealing with shared services (AKF Partners blog) strikes a chord for a platform product manager. I can attest to the issues that arise with shared platform teams: overloaded backlogs, undecipherable priorities, increased time to market, loss of ability to drive innovation.

    In the end, platform must exist to increase the speed of software products to market. As soon it becomes an encumbrance, it should be re-imagined, replaced or removed altogether. From the article:

    Remember, whatever mechanisms you put in place, your shared service or tools team should be a gas pedal and not a break for TTM.

    During planning, teams will regularly take dependencies on platform to deliver necessary features for their market. When all of the requests are summed up, many teams will be let down because their requests cannot be fulfilled.

    So, the suggestion to run internal platform components similarly to open source projects is a good one and is a fertile middle ground between complete lockdown and utter chaos. It does, however, come with taxes in the form of code reviews, merges, documentation and collaboration with other contributors. But running platform in this way allows continued innovation and a strategic roadmap while putting more control into the hands of product teams.

     

    Categories: Platforms, Product Development, Technology.

  4. Do you talk about your problems?

    Question about your company culture: Do you regularly talk about your problems? Openly? Is it okay to argue publicly? With your boss? With a VP or the CEO?

    If you answered no to any of these questions, you may have a groupthink problem. From wikipedia (emphases mine):

    Groupthink is a psychological phenomenon that occurs within a group of people, in which the desire for harmony or conformity in the group results in an incorrect or deviant decision-making outcome. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative ideas or viewpoints, and by isolating themselves from outside influences.

    I have a firm belief that progress is made through constructive conflict. When I sense that there is too much agreement among a team for too long, I question whether that team is succumbing to groupthink.

    Now, I’m not saying that teams should never get aligned around ideas and plans. At some point we have to normalize and row in the same direction. But from time to time, someone should step back and make sure the direction we’re is rowing in is a good one.

    I’m also not condoning destructive conflict. Once a resolution is reached, the team should be able to go out and enjoy a beer together, knowing they’ll slog it out again tomorrow. People who care enough to argue, typically care deeply about the subject they’re arguing about and this is a very good thing.

    Passion enables great products. Groupthink sucks.

    Categories: 100 words per day, Culture, Product Development.

  5. Why I built Giftr and What I Learned

    I built Giftr for myself. I wanted a mobile app to easily save gift ideas for my family and friends. I also took it as an opportunity to learn Ruby on Rails, jQuery Mobile, PostgreSQL, Facebook/Amazon APIs, and Heroku.

     

    Aside from the technology, the biggest learning so far is that most people don’t want to log into my app with their Facebook account. I posted Giftr on Hacker News on Saturday, November 10 and had approximately 38 hits on the index page, 12 hits on the sign_in page, and exactly 0 new accounts created. The only commenter, tuscon, had this to say:

    Interesting title. But… I wanted to try, but I don’t want to sign in with facebook. Sorry.

    I’m not planning to change the sign in approach for now, but if you don’t mind logging in with Facebook (Giftr doesn’t post anything to your wall) and would like to try it out, feel free. If you do, I’d value your feedback. You can contact me here.

    (word count: 165)

     

     

     

    Categories: 100 words per day, Giftr, Personal, Product Development, Technology, Uncategorized.

  6. This is not something the world has been waiting for

    Is matching your socks that big of a problem? Is it big enough to embed RFID chips in them to avoid that moment at work when you look down and realize you’re wearing one navy and one black?

    Turns out it is according to Samy Liechti, founder of Black Socks, but in a recent interview Liechti intimated, “This is not something the world has been waiting for.”

    There’s another name for things that the “world hasn’t been waiting for.” Innovations. Customers didn’t ask for electricity, light bulbs, cars, social networks or telephones, but industrious individuals turned these inventions into products that changed the course of history.

    The wide distribution model of the Internet allows for innovations that target niche audiences – such as the businessman who appreciates perfectly matched socks – and sustainable businesses can be built from these ideas.

    Categories: Innovation, Product Development.

  7. Two Great Customer Discovery Examples

    Customer discovery and Minimum Viable Product (MVP) are tools that we use to maximize our chances of developing valuable products that customers will love and upon which profitable businesses can be built.

    The Lean Startup approach drives development and testing of assumptions  using scientific experimentation methods that provide rapid feedback.

    This approach contrasts with more traditional product development approaches (e.g. waterfall) where a product is defined, engineered, and delivered with limited customer input.

    Many times these products fail because they missed the mark on some fundamental assumption that could have easily been tested before hundreds of thousands or millions of dollars are spent on product development.

    The first example is a Status Chart who aims to be a different kind of online resume that highlights key activities and projects instead of purely jobs. Instead of launching the full services, these guys launched a web site which explains what they are trying to do, provides a visual example, and asks users to give feedback if it’s something they’d be interested in.

    Notice that they haven’t built the service yet. This is only a test, and the perfect example of a minimum viable product: 

     

    The second example, LikeBright, was able to recruit and interview 100 customers in 4 hours. And the second, statuschart.com, built a perfect example of MVP.

    The LikeBight approach to customer recruitment technique was notable. They used Amazon’s Mechanical Turk to recruit customers.

    While this technique was innovative, there are also lots of other nuggets in this short video that explain how they targeted the customers, formulated their interview questions, and actually conducted the interviews. This approach is going to work better for consumer facing applications than for enterprise products.

    Categories: Business of Software, Customer Discovery, Innovation, Minimum Viable Product, Product Development.

  8. Enterprise Software and Employee Satisfaction

    One challenge with enterprise software, unlike consumer software, is that the people who make purchasing decisions don’t actually have to use the software they buy. Many times, large enterprise systems (like ERP packages) provide benefits to the organization as a whole to the detriment of departmental end-users.

    If people are required to interact with enterprise software to do their jobs, then it stands to reason that the products a company chooses to use directly impact employee satisfaction. And people are the most valuable asset a company has.

    Great is the opportunity for the enterprise software company who provides a valuable product that’s also highly usable. Corporate users have been conditioned all of their professional lives to expect crappy software. As Alan Cooper puts it:

    Most users don’t even realize how hard they are working to compensate for the shortcomings of a software-based tool.

    - The Inmates are Running the Asylum, 1999

    Here’s an example of one enterprise product with room for improvement (SAP). Know of others? Share them with me.

    Categories: Business of Software, Design, Product Development, Product Management.

  9. Guiding Principles

    Does your product have a set of guiding principles? How about your company?

    Defining a set of principles, i.e. the things we value, gives us a focal point on the horizon when we face choices as a team. Consider the following statement:

    We value end-user configurability over customization via programmers

    Now lets say we’re deciding how to implement a new feature which allows customers to author their own reports against our data. Our options are to:

    1. provide the customer with a reporting tool that requires the knowledge of SQL, a proprietary language, and the product data structure. Or…
    2. give them a set of user-friendly, point and click tools to configure reports without all the coding knowledge

    In most cases I can think of, #2 is way more expensive than #1. So there’s a tradeoff to be made: simple and cheap vs. robust and expensive.

    We know our users have limited access to internal IT resources and almost no tolerance for latency when it comes to getting reports. This led us to create the guiding principle above. With the principle as the backdrop, there are only a couple choices at this point a) Build the robust, expensive reporting tool or b) expend our resources elsewhere because we don’t have the resources to solve the problem the right way.

    Principles should be written and ratified with conviction. When expensive choices are encountered – in direct cost or opportunity cost – the guiding principles should aid to clarify our position and give us confidence that we’re on the right track.

    So, how are product principles created?

    • Just start – Don’t wait for them to come from management, take a stab at what you think. Bullet them out in an email and send it to the team. Be ready for the conversations that ensue and be open and flexible to change and new ideas.
    • Talk with customers – Make sure your guiding principles ultimately serve your customers/users, taking into account their specific attributes. And remember, you are not your customer, if you are not speaking and visiting with users regularly, stop reading this and go read this.
    • Iterate – Write your principles, discuss, rewrite. Don’t get married to them too early.
    • Include the whole team – Guiding principles exist so that teams have a framework for decision-making when the appointed leaders aren’t around. To make this work, the team members have to own the principles, believe in them and willingly refer back to them when they face everyday decisions.
    • Post them publicly – Make colorful, printed copies and hand them out to the team. Laminate them and hang them in the office. Put them on a page on your web site.
    • Use them in discussion – Make sure that they are verbalized regularly in conversations and when decisions are being made.

    Guding principles shouldn’t change often once set, but evaluate them regularly. Add to them, make adjustments, re-publicize every time you do.

    I’ve been involved in products and projects where guiding principles have literally saved hours of deliberation. They are especially useful in those can’t-see-the-forest-for-the-trees moments when make or break decisions need to be made.

    For a cool example, check out Google’s philosophy page (notice it’s posted publicly): Ten things we know to be true. If you know of other cool examples, share them!

    Update: Ran across another great example on Zappos.com. They randomly show their core values on every page on their site. Core value #2 “Embrace and Drive Change”

     

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

  10. The Sound of Product Development

    What does product development sound like? It’s loud. I passed though the middle of the Product Development group on the way to a meeting today and I didn’t hear the silent hiss of white noise. Nor did I see engineers heads down with headphones on. I didn’t see one person per cubicle, diligently working on pre-planned tasks.

    I saw discussions, and collaboration. I saw designers poking their heads above cube walls. I saw groups of people huddling over glowing computer monitors. Product managers sitting next to engineers.

    I saw collaboration and communication.

    True, engineers eventually need heads-down time to think through problems and make the software work. But I’m convinced that the hardest part of software development is deciding what to build in the first place and learning what customers need to be successful.

    How does this happen? Through conversations, throwing designs on a white board and testing them with customers before they become software. Through collaboration. Engineers listening to designers listening to product managers listening to engineers. The multiplier effect of a small, collaborative team is greater than the sum of its parts.

    If you don’t have this culture within your product team, try the following:

    Change the seating chart. Lower the cube walls, and put teams together rather than functional departments (e.g. design, engineering and pm). Enable casual interaction among the team members.

    Create channels for open communication. Standardize a chat tool and use Yammer or other social tools to codify discussions among the teams (for God’s sake, don’t do it via email). Make sure the tool has a good search capability so these discussions can be discovered later.

    Create the right incentives. Products are only successful if they are purchased, used and liked. Customer satisfaction and delight should be on everybody’s goal sheet. So what if your burn down charts aren’t perfect. We need tools to help us determine if we’re making progress, but those tools are a means to an end, not the end itself. If your team is chasing a meaningless metric, your users pay the price, and ultimately your company will, too.

     

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

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

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

  12. Putting all your eggs in one basket

    Two stories hit the front page of Hacker News yesterday that caught my eye. Both were about startups who lost access to key platforms. PadMapper is a user-friendly app for finding rental properties. A major source of PadMapper’s listings come (or came) from Craigslist. Pealk has developed recruiting productivity tools on top of LinkedIn for recruiters.

    These occurrences beg the question: How heavily should one partner/platform be relied upon when building a new company? Seems to me one of the key responsibilities of a founding team is to reduce risk wherever possible. When it really comes down to it, you have to look at the business model of the company whose ecosystem you’ll be joining and assess risk by asking a few questions of the model: What happens if this partnership goes away? Will my company be viable? Is the relationship symbiotic or one-sided? Do they need me as much as I need them?

    Companies like LinkedIn and Craigslist have built their businesses on very specific models, and only secondarily have become ecosystems for 3rd parties. One mustn’t forget that being a platform isn’t necessarily in their DNA. And it’s not their primary source of revenue. They provide access to one of their most important assets, their data, to entice 3rd parties to contribute to their product. But in the end this is primarily to increase their own user base.

    When a startup depends almost exclusively on a behemoth like LinkedIn or Craigslist, the imbalance is just too great and at the end of the day the startup has very little leverage.

    So what’s the best course of action if you want to join a platform ecosystem? Read and understand the terms of services, decide if you are willing to build a business within those constraints, and hope that the terms remain consistent as you build your company. It’s best to remember that at the end of the day these are corporations and the business factors are likely to override the benevolence of the engineering teams when it comes to monetizing their products.

    Categories: Platforms, Product Development, Startups.

  13. Localization Checklist

    A great site containing common localization traps. http://www.sisulizer.com/localization/traps/localization-traps-overview.shtml

    Categories: Platforms, Product Development.

  14. Solving the Wrong Problem

    I woke up to an NPR interview of author, Jonah Lehrer this morning. His book, Imagine: How Creativity Works, goes in depth on the brain science behind creativity and innovation in the workplace.

    One anecdote highlighted in the interview was particularly striking. A group of chemists at Procter & Gamble were given the task of designing a new soap for mopping floors. It turns out that this isn’t a simple problem to solve because stronger soaps, while better solvents for cleaning, can irritate the skin and strip the sheen from floors.

    After years of unsuccessful attempts the problem was finally outsourced to industrial design firm, Continuum. The first thing that Continuum did was take 9 months to observe people mopping the floors in their own homes. By watching the process they learned that the act of mopping is actually a very messy ordeal. Mops are designed to capture dirt and wringing them out is tough and often dirt is sloshed back onto the floor in the process.

    During the course of their discovery they found that subjects would often clean before the team arrived in their homes. So the designers would unwittingly spill coffee on the floor. In this experiment, the subjects didn’t go for the mop at all. They usually reached under the counter for a paper towel which they would wet under the faucet, use to wipe the floor by hand and toss into the trashcan.

    Thus, the Swiffer was invented – a disposable paper towel attached to a mop handle.

    So, what can we take away?

    Beware of solving the wrong problem – As evidenced in this anecdote, the smartest people in the world often are challenged not to start with the end in mind. According to the story, at one point Procter & Gamble had more PhD’s on staff than any other company in America. They tried to solve the problem as they saw it, but not as their users experienced it.

    [update: according to the P&G Doctoral Recruiting page on facebook, they have "more PhDs working in our core areas than Yale, MIT and UC Berkeley combined do in the same areas." (emphasis mine)]

    Observe people where they work - There is no substitute for watching users in their element when it comes to understanding the problem you’re trying to solve. We should also be careful to understand the side-effects of our discovery and design experiments that ensure we’re getting what came for. The Continuum team had to do this when they began to realize that their subjects were cleaning the floors prior to the observation.

    You’re not likely to outthink the scientists – Continuum took a different approach because they knew they couldn’t out-chemistry the chemists. Innovation is as much about the pedestrian work of learning and watching so that easier solutions can be developed to the address the really hard problems we face.

    Discuss on Hacker News.

    Categories: Innovation, Product Development, Product Management.

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

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

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

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

  17. Minimum Viable Product vs. Minimal Compliance

    Mike Holmes

    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.

     

     

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

  18. 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?

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

  19. Scale up AND Scale out – the Stackoverflow.com way

    Interesting article on the High Scalability blog this week highlights the scale up architecture of Stackoverflow.com. If you’re not familiar with this site, it’s a question and answer site for programmers that takes a new, more social approach to technical Q&A than has ever been available on the internet. Due to its usability and relevance it has become one of the top 200 web sites in the world with over 95 million page views monthly.

    While the High Scalability post highlights the scale up approach, it’s also important to note the places where Stackoverflow has scaled out. Here are a few highlights pulled directly from the post:

    • Web Tier – Web farm with 3 dedicated web servers for stackoverflow.com
    • Web Statistics – Web logs stored in a separate SQL Server database (inferred) – 20GB of logs generated per day
      • One table created per day to store statistics
    • Caching Layer (Redis) – Every request doesn’t hit the database. Sticky switches keep user requests on the same server and state can be served directly out of RAM cache
    • Content Delivery Network – CDN serves static resources for global access. Typically involves images, CSS, JavaScript, etc
    • Data – Stackoverflow.com is the largest of the sites in the Stack Exchange network and is hosted on its own database cluster in a single database, but other sites such as serverfault.com, and any of the stack exchange network sites are hosted on a separate cluster
    • Chat server is hosted in the Oregon data center while the main stack overflow site is hosted in NY

    George Beech, sysadmin for the Stackoverflow.com network notes in the original article that the data tier is only about 20% utilized leaving headroom for growth and unexpected spikes in volume.

    To achieve high scalability, there is usually going to be a healthy mix of scaling up and out. The key is to avoid painting yourself into a corner which the stack exchange guys have a done a nice job of.

    Categories: Product Development, Technology.

  20. Hurting your users, and knowing when you’re doing it

    For far too long, users of software have been marginalized by poor user experiences and interaction design. In turn simple usability flaws can introduce risk to the potential for growth in online services. If Enterprise software is your game, where employees are forced to make due with the tools they are given, nothing less than the product reputation is on the line.

    I registered for a new social career networking site called Zerply yesterday. What started as a routine journey through another online registration quickly turned into a struggle when I was required to upload my profile picture on step three of the signup wizard.

    First, Zerply lets you import a profile picture from Twitter or Facebook (great feature!), but unfortunately either there was a glitch or my profile photos were too large on both of those sites. So I resorted to my local hard drive and began the search for a suitable profile picture. If you’re anything like me you have about a gazillion pictures of your kids on your computer, but not so many of yourself.

    So now, registration incomplete, i’m in Finder spelunking for a profile photo. At this point, the odds are good that many users will abandon, however, I persevere.

    I find a profile picture that works, and begin the upload process, relieved that I’m over this hurdle. But alas, an error message: the image is too large – there’s an 800k limit. After the fact, I realize that the limit is clearly articulated under the ‘upload image’ button. So I set off to resizing the image using a desktop application. Another speed bump.

    Finally, after about 15 minutes I completed the registration process. This brought to mind a few questions

    • How many users has Zerply lost on this step, and are they aware of the problem?
    • Is this one glitch undermining adoption of what seems to be a really cool and possibly highly valuable service?
    • Do you have data to show where users are spending their time?

    So, how to fix it? Well, i can think of a couple specific things:

    • Don’t make the profile image required (turns out this is actually the case, just wasn’t obvious to me)
    • Resize images for the user on the server – there are APIs that allow you to easily incorporate this functionality into your site (for example)
    • Drop the on-screen guidance around size limit – most users won’t know what that means unless you are trying to limit your site to only technical users

    But these suggestions are beside the point. Bugs are going to happen and usability flaws will occur. It is the ability to understand, in real time, that step three is problematic and quickly course correct that sets great sites apart from mediocre ones. There are great tools out there that allow us to Measure Anything, Measure Everything in our software products. The goal of instrumenting software is so that you can see that users are getting held up and abandoning on step three, and take swift, corrective action to remove the roadblock.

    As it turns out, Zerply doesn’t require you to complete the entire account creation process before using the site. This wasn’t readily apparent to me on my first visit, so that’s something else I might change. I do believe that Zerply offers a unique take on what’s become a somewhat bloated LinkedIn experience. As a social network Zerply will increase exponentially in value as the number of users rises, so it’s important for Zerply as a company and for me as a user that users don’t abandon the signup process like I nearly did.

    Categories: Product Development, Product Management.

  21. Why your enterprise application should have a solid API

    It’s inevitable, no matter how many configuration options a software package presents, a client’s unique business requirements always tend to push the envelope of what enterprise products are designed to do. This is where an API comes in. In most cases, unless you are building a pure platform in which the API is the user interface (developers being the users), customer facing features will take precedence in your early product design.

    At some point though, you have to consider extensibility requirements among the user-facing requirements of your software and prioritize them appropriately. Otherwise you eventually lose the ability to keep up with the unique combination of configuration scenarios that customers can come up with as they use your software.

    Some product managers believe that “Every engineering hour we use to build API is an hour that we could be using to build out configuration options for feature X.” The problem with this is that not every feature of the software is worth that investment of engineering hours. And there are inevitably areas of your system that should be more extensible than others. The possibility exists that user experience could even be degraded by adding additional configuration options in some areas.

    So build API’s for areas of the system that are less critical to the end user experience, but critical to the business process. My company‘s product captures revenue and ]typically maps and posts to a General Ledger. While it is critical to get the data entry user experience correct, the actual GL integration points are much harder to abstract. There is a Cartesian product of scenarios of  how revenue maps and posts into various GL products. So API level requirements in the GL integration area should be weighted appropriately relative to the value of other features in the system, and the engineering effort associated with a highly configurable integration UX.

    Categories: Product Development, Product Management.

  22. How to Interview a Software Developer

    I have spent a lot of time over the past 10 years recruiting and hiring technical talent. There are three main things that I look for during an interview to determine if my candidate has what it takes to be a part of the team: relevant skills and experience, great communication, and passion. This article assumes you’ve already identified candidates you’d like to screen by phone (a completely separate topic).

    Relevant Skills and Experience

    I have found that many interviewers use softball questions that give interviewees the opportunity to express opinions and to project an ideal view of themselves instead of focusing on specific experiences which qualify them for a job. While this line of questioning has its merits at certain times during the recruiting process, it shouldn’t be used used to determine whether the candidate is qualified. Qualifications should focus on relevant experience.

    Macy Dog

    First we focus on job history. I have the candidate walk me through her resume while I begin to assess whether she has faced similar challenges to those she can expect in my job. Then we begin to launch into specific experience-based skill sets. For instance, “Tell me about the last time you were responsible for designing a data model from scratch,” or “Describe your last time interacting with a RESTful web service? Walk me through the service and what languages and libraries were involved? What was surprising and what did you learn?,” or “Describe to me a time you leveraged a design pattern – what problem were you trying to solve and what pattern did you use?”

    Notice these are all open ended questions with no simple yes/no or one sentence answers. These should be tailored to the specific role you’re hiring for, but remember that experienced technologists can answer questions that are timeless. They may not be able to answer detailed questions about the latest and greatest technologies because they have likely been focused on real world solutions with a slightly dated technology. It’s okay, these guys know how to learn and where to find information when they need it. Lessons they have learned in other environments will save them from repeating past mistakes.

    Oh, and another favorite question is “Tell me about the last time you really screwed up.” If your candidate can’t give you an open, candid and detailed response to this, I’d question whether or not he has taken on any significant challenges in his career. Have him walk you through how he got into trouble in the first place, but focus on what he did to recover and the ultimate outcome. You want to know what actions he personally took to address the situation, not those of his manager or teammates.

    Finally, I’ll walk through a quick case study which forces the candidate to the white board to show code snippets, data models, or other relevant diagrams. The case study should be something easily understandable within a short period of time, but representative of a real-world problem. The important takeaway from this activity is an understanding of the candidate’s thought process in real time. Is it logical or chaotic? Have they solved a problem like this before? If not, were they able to come to reasonable solution based on the information you gave them?

    Communication

    That’s the technical stuff, and it’s necessary to know your candidate has the hard skills. Jeff Atwood recently posted a great article on How to Write Without Writing, and makes the point that there’s more to programming than writing code:

    Over the last 6 years, I’ve come to believe deeply in the idea that that becoming a great programmer has very little to do with programming. Yes, it takes a modicum of technical skill and dogged persistence, absolutely. But even more than that, it takes serious communication skills…

    Often what separates good and great programmers is the difference in how they communicate and collaborate. I find this to be particularly true when I run across a candidate who has spent significant time mentoring during their career. Those who teach often have a deeper mastery of a given topic than their peers who have not, and a teach must be an above-average communicator to teach complex logical concepts.

    One of my favorite interview questions for any level hire – new developer to experienced architect – is “Teach me something, anything.” This question gives me a unique view into the candidate’s psyche. Will the topic be germane to the job or an unrelated personal passion? Candidates who meet my expectations in answering this question will usually start by clarifying what I know about the subject before launching into their lesson. Good communicators find a baseline of knowledge and work to build upon it a shared understanding of the topic at hand. This simple question can also help you gage how comfortable the candidate will be in communications with clients and senior management. Do they unknowingly patronize me or do they approach my lack of knowledge of their chosen topic diplomatically?

    Passion

    Once I’ve determined that relevant experience and communication are acceptable, it’s time to see what makes this person tick. Are they passionate about technology, and just as importantly, are they passionate about my company, my customers and the role? “What do you know about [my company]?”, or “Why [my company]?” are nice open-ended questions that let you know whether the candidate has done his homework. Are you just one of the 10′s or 100′s of companies he spamming his resume to, or is he genuinely interested in this specific opportunity? Is this a local candidate that’s desperate for a local job? Or is it someone who’s willing to move cross-country for the opportunity that you’re going to provide? (your resume screening process can actually help weed these guys out, here’s how). After all, there are hundreds of other companies out there they could be interviewing with.

    Passion for the technology itself is a must in this industry because tools and techniques literally change by the week. If a candidate is to stay relevant outside of her day to day work, she will take the initiative to stay abreast of technology developments as time allows. My favorite question to ask in this area is “When is the last time you learned a new technology just because you were interested in it?” Many candidates won’t have learned anything outside of what is required for their job. If you sense this is the case, it should send up a red flag. I’d suggest that it is impossible to keep up in this industry without making personal investments of time outside of day to day job duties and work projects.

    Conclusion

    There are many good techniques out there to help you hire great technologists. These are a few that have served me well. Once the requisite skills are verified nothing can be more important than communication and passion for most technology jobs. In fact, whether you’re hiring an engineer, professional services architect, business analyst, interaction designer, QA analyst, or any other role for your organization, your best bet is to find someone passionate and communicative. When they become employees their passion will sustain them through the inevitable rough patches, and an ability to communicate effectively could literally save you money, goodwill and reputation as you strive to delight your customers.

    Categories: Management, Product Development, Recruiting.

© Copyright Jay Nathan, 2010-2013