• Performance Linked Incentives for Engineers


    A friend recently asked me about how I might define performance for web developers. It was an interesting question coming from one startup founder to another. He was concerned with how to present performance-based incentives to his developers when performance itself is so hard to measure for engineering work. I had a few thoughts to offer him and I wanted to share them here. 

    What is Performance?

    Engineering has a complex and difficult work flow – it happens on a maker’s schedule. Understanding this, it’s extremely difficult to determine a fair objective/set of criteria by which to measure someone. Lines of code are simply not going to cut it. So what does? Shipped stories? Defect counts? As far as I’m aware, none of these have worked.

    However, if you kick the measure of performance up one level-of-altitude to overall business performance, another problem comes into play. Engineers don’t always have a direct connection to driving business value. They are charged with delivering whatever is on the product backlog in a way that is elegant, stable, and secure. Ideally, they also deliver it quickly. But whose fault is it when the backlog is less than actionable or badly organized?

    So why does performance pay at all? And, when it does, who should reap the benefits?

    This is an even harder question, and the answer varies from business to business. The core goal behind offering performance-based incentives is to ensure the business keeps working, and maybe even winning. This makes sense. And it probably makes the most sense to provide these incentives to people who are actually making the business win (i.e. managers and other strategic roles).

    The flipside is that everyone, in theory, should be incentivized to make the business win. Let’s imagine a hypothetical scenario in which this is the case:

    Step 1: Engineer looks at backlog. He realizes that the first three ideas suck.

    Step 2: Engineer pushes back because he want the business to win.

    Step 3: Product Manager reconsiders one of the ideas in the backlog.

    Even in this scenario there are potential flaws: would the incentives actually motivate the engineer over the hump of inaction? Are incentives enough or does it take a particular archetype to motivate themselves through these extra steps? (I know engineers who will push back on tasks they don’t like, even if they’re paid $1/hr.)

    What about equity?

    Startups, in theory, have a built-in incentive for all employees (or most, depending on where you are): equity. If the business sells for millions, each person will get their piece.

    But is that potential enough to rule out incentive pay? Probably not. In my experience, human beings are remarkably impatient. Most non-founders don’t think on the time horizon required to care about this outcome. Furthermore, even if the engineer does have the long con in mind, the average person needs small incentives to hold them over. (Imagine any video game. You don’t go from level one to sixty in one jump. You need all the levels in between to feel like you’re progressing.)

    So what do you do?

    I think it depends a lot on the type and scale of the business. In most creative product-focused startups, I would argue against non-stock incentive-based pay that is specific to tech goals such as lines of code, uptime, etc.

    However, I DO think that operating businesses (with real revenue) can benefit from goals that everyone can get behind (i.e. a quarterly revenue or profit goal). The case for a shared bonus pool here is reasonable, and I would argue net-positive. I like P2P systems combined with management-driven allocations. So your peers and your managers decide what slice of the total bonus pool you receive.

    The key here, however, is that it’s a BONUS. It’s NOT an excuse to pay someone less than they deserve.

    N.B. I didn’t use the term “market rate” above. I think that market rate is a faulty concept in startup land. Startups have been systematically over-funded in a way that makes bootstrapped startups totally unfit to compete. So what the market can bear doesn’t matter. What matters is how passionate someone is about the opportunity and what they are willing to work for. Generally, equity levels the playing field here.

    One final footnote: Decent bonus schemes act as a nice deferred comp plan for very early stage companies. Let’s say a new engineer wants $10,000 in annual salary, but you can only afford $7,000. You can offer that engineer $7,000 with a $3,000 bonus if the company reaches $X in revenue. This way, if you can afford it, you’ll pay it and the engineer is in a better position to bet on the company.

    In short, there is some room in an early stage company for a “company-wide performance” bonus pool. But goals have to be well-defined enough for everyone to know what they are marching towards (i.e. post-product market fit). An attempt to create a bonus system before such a time seems like putting the cart before the horse. Chances are your business won’t even work – so why create complex incentive programs?

     

     

  • Management by walking around


    Easily, one of the most fun parts of my job is management by walking around (MBWA).  It’s not just fun, but its also quite effective as a tool in leading organizations.  My experience, however, is that its an underutilized tactic.  And for those of us who do it, its one of the easiest things to ‘bump off the schedule’ for something seemingly more important.

    A brief history

    “Management by Wandering Around” is a term that was made popular by Tom Peters and Robert Waterman, the authors of the 80’s bestseller In Search of Excellence.  The concept was originally developed and touted by Hewlett-Packard executives in the 1970s.  Since HP and In Search of Excellence made the term popular, its been a reoccurring topic in business books over the years.

    What is MBWA and why should you do it?

    Simply put, Management by Walking Around (I prefer the ‘walking’ to ‘wandering’), is an unstructured approach to interacting with employees in your organization.  The idea is to ‘get out of the office’ and interact with real people doing real work in your organization.  Companies that tout MBWA often push managers to spend more time out of their offices than in their offices, if they can swing it.  The goal is to use these informal visits to listen to how employees are feeling, understand the challenges they face, gather ideas for improvement, and connect on a personal level.

    Let me start by saying that I haven’t done any formal research on the topic.  All my experience here is anecdotal, but I feel like it has served me well.  The reason MBWA works is pretty simple: the best decisions are not often made in isolation.  Its really easy, particularly when (you think) you are a smart executive, to make conclusions and solve all the businesses problems without talking to folks.  But the reality is that you get better data, insight, and ideas from talking to people who are actually exposed to the problems you are trying to solve.

    Also, as a leader in any organization, its important that you interact with people on a regular basis.  If for no other reason, this is valuable because it enables you to keep a thumb on the pulse of the organization.  When you are in your office the whole day, you don’t often get a sense for what is really going on.  Furthermore, people don’t get to connect with you on a personal level and get to know you.  Another important factor in all this is that people vary widely in their comfort level in talking with leaders and gregariousness.  So, if you are not out there actively seeking out conversations, there is some distinct population of your team that you just aren’t going to hear from.

    How do you do MBWA well?

    The truth is, I am still working on getting good at this whole MBWA thing.  I’ve learned a thing or two so far, but I certainly have a ways to go.  Here’s what I’ve got:

    • Do everything you can to be consistent with your MBWA time.  Things always come up.  That’s no excuse, though.  Every manager is busy.  Just be disciplined about not giving this time up.
    • Your demeanor matters.  One valid reason to actually cancel MBWA time is if you are upset, angry, or just not in the right mood to walk around and chat with others.  People can read your feelings, and some people don’t get to see you very often.  Don’t leave a lasting impression of uneasiness with them.
    • Don’t be selective.  Try to get out there and actually talk to everyone.  Just talking to some people gives you a skewed sample of the team data.  Also, it makes people feel left out.
    • Ask for suggestions and ideas.  Don’t keep the conversation overly tactical.  It’s not just about you ‘coming by’ to inspect the work they are doing.  Its about learning from them.
    • Chat about ‘life’ too.  You don’t have to keep topics limited to work.  Its important to connect with people on a personal level, too.

    I continue to learn more about this tool every day.  I’ll continue to employ it and report back with my results.  I hope it works for you, too!  Please post comments with anything you’ve learned!

  • What is Net Promoter Score (NPS) and how is it used?


    I first read about Net Promoter Score on Eric Ries’s blog almost a year ago. I found the concept to be really compelling. In recent conversations with lots of budding entrepreneurs, I have realized that not everyone is really familiar with NPS. So I thought a quick overview could be helpful.

    (more…)

  • Kanban and Agile Software Development — Part 3


    Where we left off

    In the introductory Kanban post, I provided some background on Kanban and in Part 2, I went on to discuss several ways Agile and Kanban have been put into practice together, including examples of some of the several different ‘flavors’ of Kanban being used in software development.

    Now I want to discuss some of the key tradeoffs that might occur in using Kanban systems for agile development, leave you with some food for thought and discussion, and provide some resources for digging into the topic further if I’ve stirred your curiosity a bit.
    (more…)

  • Kanban and Agile Software Development — Part 2


    Where we left off

    In the introductory Kanban post, I provided some background on Kanban in order to give you some context for how Kanban might be used in an agile software development environment. Now I want to provide some insight on how Kanban is currently being used with agile and why I think the idea of doing so holds some merit.

    In Part 1, I mentioned that Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum. I also said that at the very least, incorporating Kanban into an agile environment by combining rules 5 and 6 of Toyota’s Production System (TPS) seemed to make the most sense. In other words, using Kanban as a means for fine tuning in order to stabilize and rationalize the process could bring a lot to the table in an agile software environment.

    Let’s take a look at some of the ways it’s been done so far.

    How has Kanban been implemented in an agile software environment?

    In his article, Kanban Applied to Software Development: from Agile to Lean, Kenji Hiranabe discusses several ways Agile and Kanban have been put into practice, including:

    • Agile Kanban
    • Sustaining Kanban
    • Lean + Agile Kanban
    • Portable Agile Kanban
    Agile Kanban

    Hiranbe equates Agile Kanban to ‘Task Kanban’ in that, like Agile, it doesn’t show processes, such as Development, Testing and Deployment, but instead relies only on visual cues that show the status of a story, such as To Do, Doing and Done. He uses this photo of a Task Kanban implemented by the JUDE development team at Change Vision, Inc. to illustrate:

    Agile Kanban Board

    Agile Kanban Board

    Sustaining Kanban

    Unlike Agile or Task Kanban, Sustaining Kanban has separate and serial processes (Development, Testing, etc.) and the Kanban cards move between those processes from left to right, as shown in this example, a pieced-together image of Yahoo’s Kanban system from Jeff Patton in his article, Kanban Development Oversimplified.

    Sustaining Kanban Board

    Sustaining Kanban Board

    How Yahoo’s Kanban board works:

    • The circled numbers along the bottom are the number of stories allowed in the corresponding column.
    • The boxed numbers in the left column represent an approximate wait time in days, so items at the bottom will have a slightly longer wait time than those higher up on the board.
    • Stories start on the left side and move to the right across the board as they progress through various phases of development. Those in the top row are in progress. As they complete a phase and move to the right, stories below them are moved up.

    Although at first glance you might think otherwise, Hiranbe explains, “Sustaining Kanban is not a classic waterfall process, where all the requirements are ‘designed’ at one time, ‘developed’, and ‘validated’ at another time, which would cause all the cards to move in a group. Instead, the cards move one by one, like the one-piece-flow of manufacturing.”

    Using the Yahoo example, you can clearly see the “flow of work” concept used in Sustaining Kanban is different from the “iteration” concept of agile. And, in order to be a true ‘pull’ system, rules would need to require that only the next group to the right is allowed to move the cards on the board.

    Lean+Agile Kanban

    Hiranbe describes Lean+Agile Kanban like using Agile Kanban synchronously within each process and using Sustaining Kanban asynchronously across the whole value stream of processes

    Kanban-nano

    Patton also found a smaller “portable” Kanban system he in a project being developed by Central Computer Services, Co. At Central, a team works in several smaller sub teams (usually pairs). When a sub-team pulls a user story, they break it down into their tasks and post them onto their own portable Kanban board (in this case, a bulletin board they can carry with them).

    Kanban Nano

    Kanban Nano

    In Central’s case, the Kanban system consists of two levels:

    • A project level in which a card represents a user story.
    • A team (or a pair) level where a card represents a task.

    Central uses the term ‘Kanban-nano’ to refer to its agile-Kanban system.

    It’s just another way to be agile!

    The idea of using a simple task board with index cards or sticky notes is as old as Agile itself.

    Even after seeing only a few styles of Kanban in place for agile software development, it’s certainly not a stretch to imagine other variations that could be used in order to create hybrid agile-Kanban systems. One example is Scrumban, fully discussed by Corey Ladas in his 2008 paper, in which he describes Scrumban as “Incrementally enhancing Scrum with more and more pull-like features.” In doing so, Ladas says, flow becomes smoother as process capability improves, providing opportunities for kaizen.

    The beauty of the Kanban system: it’s very visual. If logjams occur they’re obvious and action can be taken to address them.

    Over time, the process of improving the system is considered ‘smoothing’ or production leveling, and is sometimes referred to in production as “heijunka”. It’s a technique for reducing waste and is an important part of the production efficiency in the TPS and in lean manufacturing in general.

    So, at least to this point, you might agree as I said in part 1:

    “At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process.”

    But what are the tradeoffs?

    Phew, that’s enough to read for now. In Part 3, I’ll discuss some of the tradeoffs that might occur and if bringing Kanban into an agile environment necessarily means we lose the collaboration between teams with different perspectives, a very important part of product development in my mind.

    I’ll also provide some additional resources you can use to find more information on using Kanban in an agile environment.

  • Kanban and Agile Software Development — Part 1


    I’ve never made it a secret that I am a fan of agile management practices, both inside and outside of software development.  Historically, however, two things within the agile space have always been a little bit frustrating to me:

    1. First, folks too often view different flavors of agile as competitive instead of complementary.  I hear questions like, “What’s better?  Scrum or XP?”
    2. Secondly, there aren’t that many great resources for learning about the practical reality of implementing agile within an organization.

    I have heard about Kanban systems applied to software development for a while now, but mostly through conversations with other agile practitioners. After doing some research, I’ve found that there were not many resources on the internet about Kanban and how it is used in agile development.  So I decided to pull something together here and use it as a basis for further discussion.

    Kanban’s origins and use as a JIT manufacturing tool

    First, what exactly is Kanban?

    The word kanban is Japanese. Roughly translated, it means ‘signboard’, ‘billboard’ or ‘card you can see.’ In its original usage in 17th century Japan, Kanban was a wooden or metal sign often used to represent a trademark or seal.

    In more modern times, however, Kanban became a term used in Just-in-time (JIT) manufacturing systems that seek to reduce in-process inventory and its associated carrying costs, most notably by Toyota. Thus the concept of Just-in-time manufacturing has also become known as the Toyota Production System (TPS).

    JIT or TPS is a lean, pull system of production. American manufacturing has traditionally been based on a push system where the manufacturer estimates the quantity of product it must produce in order to meet forecast demand. A push system can result in either a shortage or surplus of materials needed for production depending on the accuracy of that forecast.

    Conversely, pull systems like those used in the TPS rely on observed and not forecast demand. Signals at different points in the process are used to determine when more parts are needed. To illustrate the concept simply, imagine a parts bin on the factory floor with a Kanban card (signal) inside that carries part identification. When the bin is empty, the bin and the card are taken to the factory’s store for replacement. The factory store replaces the empty bin with a full one containing its own Kanban card. The factory store then presents the empty bin and its Kanban card to the appropriate step in the supply chain for replenishment.

    In such a system, as long as there is one spare in the factory store, the process will never run out of needed parts and supply costs are only incurred when they’re actually necessary.  While it may not seem revolutionary at first blush, it turns out that it is.  This subtle shift in thinking can have a dramatic impact on efficiency and waste.

    The general flow of Kanban would look something like this:

    Kanban Process Simplified

    Courtesy of leanandkanban.wordpress.com

    OK, so software development isn’t manufacturing

    By now, you’re probably thinking:

    “This is all well and good in a factory production line, which is a very linear process where the product moves from one assembly stage to another in orderly fashion and once the product moves form point A to point B, it doesn’t come back (provided quality is satisfactory when it arrives at point B). But software development doesn’t always operate in a linear process.”

    It’s true that flow is often non-linear with software development. It’s not always a clean handoff from elaboration to development to testing.  Sometimes design and development are happening in parallel, for example. Plus, we’re talking about labor and not physical, raw materials.

    However, Kanban is in use in lean non-manufacturing environments and, in fact, Kanban has already been adopted in some agile software development environments. That’s likely because Kanban is relatively easy to adapt to specific environments because there aren’t a lot of rules.

    The 6 rules of Kanban and the TPS implementation of Kanban

    Kenji Hiranabe1 succinctly lists the rules of Kanban as:

    1. Customer (downstream) processes withdraw items in the precise amounts specified on the Kanban.
    2. Supplier (upstream) produces items in the precise amounts and sequences specified by the Kanban.
    3. No items are made or moved without a Kanban.
    4. A Kanban should accompany each item, every time.
    5. Defects and incorrect amounts are never sent to the next downstream process.
    6. The number of Kanbans is reduced carefully to lower inventories and to reveal problems.

    And, in fact, Toyota’s TPS itself has only six very simple rules:1.

    1. Do not send defective products to the subsequent process.
    2. The subsequent process comes to withdraw only what is needed.
    3. Produce only the exact quantity withdrawn by the subsequent process.
    4. Equalize production.
    5. Kanban is a means to fine tuning.
    6. Stabilize and rationalize the process.

    In non-manufacturing environments, the primary purpose of Kanban is to facilitate efficient workflow. In manufacturing it’s about having the right part in the right quantity at the right time. This is as opposed to producing based on guesswork and estimation.  It’s about being lean. Very lean.

    Can agile and Kanban coexist happily?

    The real question then, is “Does Kanban conflict with Agile concepts/principles?”
    The best answer might be, “In some ways, maybe. In some ways, maybe not.”

    Over the last several years a large number of Agile practitioners have begun to include thinking from lean manufacturing in their Agile approaches, thanks to trailblazers like Tom & Mary Poppendiek in their book Lean Software Development. But Kanban, at least as discussed thus far, seems to break the primary rule of today’s common agile practice: the fixed development time-box. Kanban systems are continuous, not iterative, yet both exist to promote workflow efficiency.

    In his article, Kanban Development Oversimplified, Jeff Patton illustrates some of the conflicts between Agile and Kanban. With Kanban development:

    • Time-boxed development is out
    • Stories are larger and fewer
    • Estimation is optional or out completely
    • Velocity is replaced by cycle time

    Implementing Kanban in an Agile environment might require a bit of ‘shoehorning’ to make it work. But Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum.  In this way, they certainly seem complementary.

    At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process. And, just as Agile has evolved into several different flavors over time, like XP and Scrum, it’s not a stretch to imagine Agile-Kanban hybrids like Scrum-ban just might create a synergy for software development that neither could achieve on its own.

    Where do we go from here?

    I’ve laid the groundwork by providing some context on the possibility of using Kanban in an Agile software development environment. Just as I think different forms of Agile shouldn’t be seen as conflicting but as complementary, I also think it’s important to keep an open mind and consider that Kanban and Agile have the potential to be complementary and not contradictory.  The subtle shift in lean thinking turned out to be revolutionary in classical production, and it may just have a significant impact in the world of agile as well.

    In Part 2 I’ll take a look at how Kanban is currently being adopted in Agile environments and the key tradeoffs that might result.

  • The Right Way to Fight


    The term ‘conflict’ typically carries with it negative connotation.  But it’s something I have been thinking a lot about lately, and I feel like conflict is not necessarily a bad thing.  As our company continues to grow at a very rapid trajectory, there are lots of new faces, roles, and even whole organizations.  Managing the responsibilities and roles during the growth has been a challenge, to say the least.  The reality, however, is that friction in this kind of situation is unavoidable.  I’d even go as far as to take that a step further.  I am not sure I want to avoid it.  I think that open and healthy dialogue about disagreements can be a good thing.

    I was happy to see that my thoughts on the topic of conflict were seconded by many authorities in the management arena. There is a fascinating book titled: “The Right Fight”, which espouses the belief that conflict is a welcome element in any organization. The authors have coined the term “productive dissent”, which is essentially harnessing the power of well organized and respectful debate.

    Don’t be afraid to pick the ‘right fight’

    For most people, including myself, the last thing we desire is an argument. However, when working in a collaborative environment, some level of conflict is unavoidable. The key is using disagreements as a catalyst to improve our overall work environment and customer experience. This may sound far fetched, but I have seen where productive dissent has been a powerful tool.

    If you think about it, to stay competitive in the marketplace, a company must continuously evolve. Stagnation literally equals death, no matter how good your initial product or service is. Technology, the competition, and customer expectations will demand constant improvement. Embracing the principles of the “right fight” is a great way to stay on the cutting edge.

    So, what does that really mean?

    Harnessing the power of collective wisdom

    I am very fortunate to be a part of an organization filled with extremely intelligent and motivated individuals with  diverse backgrounds of experience. However, inherent in this is the fact that, at times, we may disagree with each other about the specs of a project, the ideal organizational structure, or the best process. Instead of agreeing to disagree, we should instead aim to get all thoughts and perspectives placed on the table for consideration. When you approach issues in this way, wonderful things can happen.

    It’s often not until you really get into someone else’s thought process by allowing full and honest discourse, that you uncover the gems of innovation and creativity. In this Euntreprenuer.com article titled “Conflict in the Workplace”, the columnist stresses the point that for a leader, “How employees deal with conflict is usually a direct reflection of the tone or atmosphere you set for your company. If you shy away from conflict, so will your employees. If you confront others in a negative manner, so will they. If you embrace conflict as a potentially positive engagement between individuals or groups, they will, too.”

    This statement made me reflect on my own management style and manner of handling conflict. While I always make a conscious effort to be inclusive of the viewpoints of others, I am sure that I can do more to foster a culture that appreciates and grows from any disagreements we may have. My ultimate goal is progress and I fully embrace it — no matter what the source.

    Jeff Weiss, a prolific author on collaboration in the workplace is quoted in the Harvard Business Review as saying “Assume you have something to learn, assume there is a more creative solution than you’ve thought of.” This wisdom, along with striving to identify common ground and branching out, are keys for the successful resolution to workplace conflict. This is advice that can be used in our interactions within the company structure, as well as in our everyday lives.

    Give it a try

    To me, good teams are built on healthy relationships.  Healthy relationships don’t mean that avoidance of conflict.  In fact, they mean quite the opposite.  Healthy relationships are about trusting someone enough to share your honest feelings with them, even when that means you disagree.  In the end, you and the other person are better for it.  And perhaps most importantly, the whole company is better for it.

    The next time you encounter a conflict, employ the principles of the “right fight” and observe the outcome. I would love to know how it works out for you.  (I’ll certainly let you all know how it works out for me…)

  • Throw out your product specs…


    I don’t like requirements documents. There, I said it.  I’ve been thinking about this latently for a number of months now, but all of this thinking really caught up with me this weekend.  We’ve been thinking a lot lately about evolving our product management practices and there are no shortage of opinions around the office and from experts in the community.  As such, I’ve tried to do a lot of listening, reading, learning, and reflecting over the last few weeks.  Here’s what I’ve come up with so far.

    There are many flavors of requirements out there.  Depending on the product management practices you use, you are likely to have some of the following: product requirements documents (PRDs), market requirement documents (MRDs), business requirements documents (BRDs), software requirements specifications (SRSs), and feature specifications (FSs).  For the sake of simplicity, I’ll just refer to all of them as PRDs or specs.

    There are a number of shortcoming with PRDs. I’ll take the time to just list a few here:

    • They take a long time to write.  Also, they aren’t super useful until you are done writing.  (Think of the value curve as a stair-step function)
    • They are not enjoyable, engaging, or interesting to read.  Ergo, they aren’t read often.
    • Similar to the above, but potentially worse: they are nearly impossible to ‘diff‘ in most typical formats.   Which, for a living document, is bad.
    • They give people a false sense of security.  You read through that fifty pages and you think, ‘wow, we got this thing completely specced out.’  Wrong.  See below.
    • They don’t cover the most important of the product: the user experience.

    Let’s talk about what a good spec should do

    To me, a good set of requirements is supposed to describe a product that we are reasonably confident will be successful in front of real users.  But why does it exist in the first place?  Well, it’s core purpose is to facilitate discussion and decision making around the product in question.  Typically, there are a lot of stakeholders (with a lot of different paradigms) around that table: QA, Engineering, Marketing, Merchandising, Operations, Executives, etc.  So a good spec is able to quickly communicate what this product does and how it will do it.  The goal of such a specification is to create more clarity than confusion.  It should be your single source of truth.  Finally, a sustainable spec is one that is built for change.  Your product will no doubt evolve and change as you gain more insight from users.

    Delivering on all the expectations of a good specification is much easier said than done.  There are a lot of things that a spec has to do, and it’s only really useful if you can create it in a reasonable amount of time.  Furthermore, in most typical formats, the spec ends up getting thrown in the trash after the product is launched.  So you really don’t want to invest that much time into it.

    Also, there is a timing issue here.  How can we have any degree of confidence that our product will be successful without actually having tested the product in front of real users?   If you look at most specification creation processes, you’ll find that people are writing tens or hundreds of pages well-before they’ve actually put anything in front of a user.  What’s worse is that they haven’t even begun to think about the interaction or visual design of the product yet.   That’s counterintuitive to me because it goes against the most important rule I have learned in my time managing products: The user experience is the most important part of any product. It’s not about ‘what it does.’  It’s about ‘how it does it.’

    Now don’t get me wrong.  Some really forward-thinking product teams actually pay close attention to interaction design and visual design in their PRDs.  Some of them actually sketch out ideas and test them in front of users while building their requirements documents, which is a huge win.  If you are in that select group of forward-thinkers, you are definitely a step ahead.  But, in this scenario, there is an obvious question that we are left with: if you are actually beginning the process of product discovery (and doing real user testing), why are you using a document as the format to store your findings and insights?

    The ‘aha’ moment: prototyping

    When we look at all of the things that a specification is supposed to do well, it becomes clear that building a good one is a really tall order.  But when we combine the goals of communicating the needs of the product with actually validating/discovering the solution, an answer emerges: a high-fidelity prototype!

    The beauty of a high-fidelity prototype is that it actually provides people with a realistic sense of the user experience of the product.  A good prototype describes the functionality of the application while leaving very little room for imagination.  High-fidelity, to me, means that the interface is clickable, but that the backend is not necessarily functional.  In most cases, it will be ‘stubbed’ or simulated.  While every single corner case need not be designed, the major use cases and features should be fleshed out.  After all, the idea is to capture the proposed user experience.

    Imagine the kind of robust dialogue that can be had around a high-fidelity prototype versus a 50-page spec.  All of a sudden, these disparate stakeholders with very different frames of mind, will all (literally) see the same thing.  They will not only have a sense of what the functional requirements are, but they will see the proposed information architecture, user flow, interaction, and visual design.   They can actually understand how this product will come together and will have a much more robust understanding of what it means to them.  Also, they’ll have a single source of truth.  No need to dig through several email chains to find the answer to the question about a certain use case.  Just click through the prototype to find your answer.

    If you think a high-fidelity prototype will help facilitate discussion and decision making around a product, just wait until you see what it does for your engineering team.  Beginning engineering without having fleshed out the user experience can be very costly.  Typical specs are so ambiguous that the really tricky product management decisions are faced only after the engineers have begun writing code.  Also, typical written specs leave so much open to interpretation that its very likely engineers will write code that doesn’t do precisely what you intended.  This usually creates time pressure for PMs and engineers.  The pressure generally causes them to make hasty decisions without user input and to re-write code without taking the time to be thoughtful.

    But a high-fidelity prototype changes a lot of that.  The experience has been thought through much more significantly by the time the engineers begin writing (back-end) code.  Furthermore, there are few (if any) better ways to communicate the needs to an engineer than to show them precisely how the application is supposed to behave.  They can actually foresee some of the challenges ahead and can be much more thoughtful about the architecture.  That’s not to mention that their velocity is likely to increase because they have more clarity on what they are building.

    Last, but certainly not least, is the effect on the user.  The great thing about using a high-fidelity prototype as your ‘source of truth’ is that you can actually put it in front of users to get feedback.  This enables you as a product team to ‘test early and often.’  And instead of taking all that extra time to ‘write up’ your learnings from user testing, you can just work with the interaction team to evolve the prototype.  Which means you can iteratively test it again and again until you’ve gotten the experience right.  You are able to test much more easily at this stage because the cost of change is so much lower than it will be further downstream.  Once you are ready to begin implementation on the prototype, no additional administrative work is needed (in the form of writing pages and pages).  Instead, you can just begin involving engineering in the discussions around the prototype and they can begin turning it into a real product.

    Give it a whirl

    If you’re a skeptic right now, that’s OK.  It’s likely that your existing process is painful enough that you’ll get open-minded about this sooner or later.   Next time you have the opportunity to create a product spec, you should consider working with your design team on creating a prototype instead of spending weeks or months writing a longer PRD.  Get that prototype in front of real users (and the rest of your product team and stakeholders) and use it as a catalyst for dialogue and decisions.  When it comes time to implement, bring your engineers into the conversation.  I think you’ll be pleasantly surprised at the result.

  • Magma rails is happening right now :)


    I am thrilled to see the agenda for Magma Rails coming together.   I have a real sense of pride in the fact that I helped start the company (Crowd Interactive) that is putting on the first ever Ruby on Rails conference in Mexico!  What’s more is that it really looks like it is going to be a great conference.

    Some amazingly talented people will be giving talks there, and I am happy to say that I know a few of them personally.  The ones to really look out for will be by:

    • Jon Dean
    • Marcelo Serpa
    • David Padilla
    • Edwin Cruz
    • Jorge Pardinas
    • Juan Esparza
    • Karla Magana
    • Luis Galaviz
    • Roberto Cataneo

    I am truly heartbroken that there won’t be a live webcast of the conference.  I wasn’t able to be in Mexico this year for it, and it would have been nice to tune in!  That’s OK.  I’ll try to make it out next year.  I’ll be looking out for all the #MagmaRails tweets.

    Anyway, I am really proud to have played some small part in the rails revolution happening in Mexico.  Kudos to all the Magma Rails and CI guys for taking it a step further.

  • Product Management vs Interaction Design


    One of the questions that gets escalated to me most often these days is some permutation of, “What is the difference between product management and interaction design?”   It is particularly hard to answer questions like “where does one end and the other begin?”  These are not simple questions to answer because the roles do have some overlap and it is important that both of these roles collaborate closely in any organization.

    Before I answer the question, I should say two quick things:

    • My goal, as a leader, is two-fold when it comes to defining roles.  First, I aim to preserve a sense of ownership between the various members of the team developing a new product.  Second, I want to ensure that there is a clear system for collaboration among the team.
    • It’s important to note that my answer to this tough question is a work in progress.  I am trying to figure it all out as I go, so bear with me.

    What is product management all about?

    To me, product management is really about two things:  1) defining and assessing the market opportunity.  2) working with the cross-functional product development team to discover a solution.  Here are some of the core activities that come to mind:

    • Assessment: Whatever product you are working on, you are typically addressing some sort of gap or market opportunity.  In this case, the first goal is to figure out if the project is even worth pursuing.  It needs to be quantified and thought through, along with the overarching product strategy, to see if it is a good fit.
    • Stakeholder management: There are a variety of stakeholders, both inside and outside the organization, that should be brought to the table when working on a product.  The PM is responsible for bringing these stakeholders to the table and understand what a successful product really is from their perspective.  Another part of stakeholder management is keeping folks up-to-date with the evolution of the product, since it may effect them.
    • Building requirements: As the product is being discovered by the PM, and potential solutions present themselves, requirements need to be built.  The PM is the driver of this process.  Good requirements outline the core opportunity, and what a success looks like for addressing the opportunity.
    • Validating solutions: As solutions get designed and built, the PM should be validating those solutions against the initial opportunity assessment and the product requirements.

    Of course, the job of a PM on a good product team becomes very iterative.  Few, if any, good products are developed linearly.  Instead, new information and insight is yielded throughout the process, which drives updated requirements and solution-validations.

    What is interaction design all about?

    Interaction design (IXD) is a partner organization to the product organization, much like engineering is.  (More on this later…)  An IXD’s goal is to build something that is usable and valuable for the end-user.  A good IXD gets at this goal in two ways: 1) getting to know and understand the user 2) thinking through (in detail) and ideating potential experiences for the user.  Some of the core activities that come to mind:

    • Understanding the user. The IXD has many stakeholders to think about, but none is more important than the user herself.  This can be done many ways, but typically takes the form of surveys, focus groups, and competitive analysis.  Often times, these activities are taken on by a peer to the IXD known as the user experience researcher (UXR).  More on this later, also.
    • Thinking through the details. The Product Requirements map out high-level definitions of the problem landscape and what success looks like.  The IXD is taking this to the next level of detail, where many unanswered questions still exist.  The IXD is the person driving these answers.
    • Conceptualize solutions. While high-level requirements can typically be written out in sentences in something like a product requirements document (PRD), more detailed solutions need more than just words.  The IXD is the person who is conceptualizing detailed solutions in a higher fidelity way that can be used to gather feedback from stakeholders and users alike.  Typically, these take the form of storyboards, screen flows, wireframes, and prototypes.

    The interaction designer has a lot of work cut out for herself.  The key to doing a solid job is to have the time needed to do the right kinds of discovery as well as being iterative in conceptualizing solutions.  Again, learning about the customer is not a linear process.  Often times, new information and insight is brought to light in the middle of the design cycle.  This is why being agile and iterating on design is so important.

    Both IXDs and PMs have to collaborate to make it work

    It doesn’t matter how detailed we are about dividing up roles and responsibilities between IXDs and PMs.  At the end of the day, they both have a lot of shared responsibilities.  They both need to be connected to customers and stakeholders.  They both need to be iterative and work with end-users to understand if needs are actually being met.  They both need to be willing to change their deliverables (whether they are product requirements or prototypes) based on new insights that are brought to light.

    Product management and interaction design is a close collaboration no matter how you slice it.  I view PM as a bit higher-altitude when it comes to defining a solution.  IXD is closer to the ground, and has much more of a hand in defining how the experience comes together.  While both groups need to work to respect boundaries and allow the other group to do its job, they both need to work hard to be on the same page.  If PM and IXD cannot work together in harmony, then you are destined to have a product that just doesn’t feel right.