Gibson, David, 1957- author

Gunderson, Chuck, author

Croggon, Alison, 1962- author

Hexel, Vasco, 1980- author

Pizzato, Mark, 1960- author

Lutterbie, John Harry, 1948- author

In a recent article for Rain Taxi, Graziano Krätli reviews Fabiano Alborghetti’s Directory of the Vulnerable, translated by Marco Sonzogni. He begins by stating, “Fabiano Alborghetti’s two fine collections to date, L’opposta riva (The Opposite Shore, 2006 and 2013) and Registro dei fragile. 43 canti (2009; Directory of the Vulnerable) represent almost an anomaly, if […]

We recently sat down with Pratap Reddy to chat about his new collection of short stories, Weather Permitting & Other Stories, which will be released by Guernica this spring. GE: Pratap Reddy, please tell us about your new book. PR: Weather Permitting & Other Stories is my first book. It’s a collection of short stories. […]

All you poetry lovers, check out this wonderful documentary that will be airing on the CBC website March 25th! In this CBC Radio One Special Program, Where Have All the Poets Gone? Sook-Yin Lee gives “a surprising look at the conditions that inspire Canadians to express themselves through poetry.” Here’s a blurb about the documentary: […]

We recently sat down with F. G. Paci to chat about his new collection of short stories, Talk About God and Other Stories, which will be released by Guernica this spring. GE: Could you tell us about your new book, and about some of the stories in the collection? FGP: TALK ABOUT GOD and Other […]

Congratulations to David Huebert, the winner of this year’s CBC Short Story Prize! David won this year’s short story competition with a story entitled “Enigma”, which is about a woman who must end the life of her beloved horse. As he explains in a recent article by David Burke, the idea for the story came […]

Quick! Think of the word “developer” or “coder” — what’s the first thing that comes to mind? Maybe a whiteish male in his twenties living in a busy metropolis, wearing a nerdy t-shirt and hoodie? Someone a bit like Mark Zuckerberg? Or maybe a younger Bill Gates or Sergey Brin? Any of the dudes from the HBO series Silicon Valley, perhaps? Certainly no one like me.

By tech standards, I’m old. I’m also female and a mother. I live in a midwestern town you’ve never heard of and will never visit — a town where the cows vastly outnumber the people. My hair color is (almost) natural and is no longer part of the ROYGBIV collection, so I have no perceived conference street cred. I own about a thousand geeky T-shirts, but never actually wear them in public, opting for more “girly” attire (or so was pointed out by a male colleague). On the surface, I look more suited to taking notes at a PTA meeting than writing code. I’m a bit of an outsider. A tech misfit.

So when my 11-year-old daughter finished her recent coding camp and excitedly declared, “Now I’m a real developer, Mom, just like you!” there was the usual parent pride, but also a small piece of me that cringed. Because, as much as I support the STEM fields, and want the next generation of girls to be coding wizard-unicorn-ninjas, I really don’t want my own daughter to be a developer. The rationale behind this bold (and maybe controversial) statement comes from a place of protection. The tech world we live in today is far from perfect. I’ve endured my share of misogyny, self-doubt, and sexual harassment. Why wouldn’t I want to protect her from all of that?

The (diversity) elephant in the (computer) room

You’ve heard this story before: there is not enough diversity in tech. This puzzling trend seems to continue year after year, even though numerous studies show that by including more people from underrepresented communities, a company can increase its innovation, employee retention, and bottom line. Even with the recent push and supposed support for diversity and inclusivity from many Fortune 500 companies, women and female-identifying people still only hold 20% of all top tech jobs.

The data from FY 2018 shows that the number of women in technical roles at three of the top tech giants was 24% for Adobe, 26% for Google, and 22% for Facebook. While these numbers show that there is still not enough representation for women, these numbers do reflect a slight increase from the previous year (FY 2017: Adobe 22%, Google 25%, Facebook 15%). But even with this upward trend of hiring women in tech roles, the marginal growth rate has not caught up with the real world. The tech workforce is seriously out of touch with reality if, in 2019, a demographic (women) that represents more than half the global population is still considered a minority.

Sometimes this lack of diversity at the top level is blamed on a “pipeline” issue. The logic being: “If there are not enough girls who learn to code, then there will not be enough women who can code.” However, programs aimed at teaching girls how to code have skyrocketed in the past few years. Girls now make up about half of the enrollment in high-school coding classes and are scoring almost identically to their male classmates on standardized math and science tests, yet, young women make up only 18% of all Computer Science degrees. I have to wonder if this steep drop in interest has more to do with lack of representation in the tech sphere, than with girls and young women simply not being “smart enough” or “not interested” in working with code? At the very least, the lack of representation certainly doesn’t help.

Of course, the diversity picture becomes even more abysmal when you consider other underrepresented groups such as people of color, people from the LGBTQ community, and people with disabilities. And while I really don’t like glossing over these deeper diversity issues in tech, because they are abundant and are much more grotesque failings than the male/female ratio, I also don’t feel qualified to speak about these issues. I encourage you to look to and value the voices of others who can speak with higher authority on these deeper diversity issues, such as Ire Aderinokun, Taelur Alexis, Imani Barbarin, Angie Jones, Fatima Khalid, Tatiana Mac, Charlie Owen, Cherry Rae, and so many others. And for those readers who are new to the topic of diversity in tech, watch Tatiana Mac’s recent conference talk How Privilege Defines Performance — it’s well worth the 35 minutes of your life.

The four stages in the digital accessibility journey

However you look at it, the numbers don’t lie. There are some pretty significant diversity issues in tech. So how do we fix this issue before the next wave of young developers join the tech workforce? Simple: teach developers to write accessible code.

This may seem like a joke to some and stretch to others, but hear me out. When we talk about accessible code, what we are really talking about at its core is inclusiveness. The actual process of writing accessible code involves rules and standards, tests and tools; but inclusive development is more abstract than that. It’s a shift in thinking. And when we rethink our approach to development, we go beyond just the base level of simple code functionality. We instead think, how is this code consumed? How can we make it even more intelligible and easier for people to use? Inclusive development means making something valuable, not just accessible, to as many people as we can.

That line of thinking is a bit abstract, so let’s go through an example. Let’s say you are tasked with updating the color contrast between the text on a webpage or app and the background. What happens at each stage in the accessibility journey?

Stage 1: Awareness — You are brand new to digital accessibility and are still trying to understand what it is and how you can implement changes in your daily workflow. You may be aware that there is a set of digital accessibility guidelines that other developers follow, but you are a bit hazy on what it all means in a practical sense.

Stage 2: Knowledge — You know a bit more about digital accessibility and feel comfortable using a few testing tools, so you run an automated accessibility test on your website and it flags a possible issue with the color contrast. Based on your awareness of the guidelines, you know the color contrast ratio between the text and the background needs to be a certain number and that you need a tool to test this.

Stage 3: Practice — Feeling more confident in your knowledge of digital accessibility rules and best practices, you use a tool to measure the color contrast ratio between the text and the background. Then based on the output of the tool, you modify the hex code to meet the color contrast ratio guidelines and retest to confirm you have met the accessibility requirements for this issue.

Stage 4: Understanding — You understand that the accessibility guidelines and tools are created with people in mind, and that code is secondary to all of that. One is the means, and the other is the end. In the color contrast example, you understand that people with low-vision or colorblindness need these color contrast changes in order to actually see the words on your web page.

This is a bit of an oversimplification of the process. But I hope you get the gist — that there are different stages of digital accessibility knowledge and understanding. True beginners may not be to even stage one, but I am finding that group rarer and rarer these days. The word about digital accessibility seems to be out! Which is great; but that’s only the first hurdle. What I’m seeing now is that a lot of people stop at Stage 2: Knowledge or Stage 3: Practice — where you are aware of the digital accessibility guidelines, have some testing tools in your back pocket, and know how to fix some of the issues reported, but haven’t quite connected the dots to the humans they impact.

From the standpoint of getting daily stuff done, stages two and three are okay stopping points. But what happens when the things you need to do are too complex for a quick fix, or you have no buy-in from your peers or management? I feel that once we get to Stage 4: Understanding, and really get why these kinds of changes are needed, people will be more motivated to make those changes regardless of the challenges involved. When you arrive at stage four, you have gone beyond knowing the basic rules, testing, and coding. You recognize that digital accessibility is not just a “nice to have” but a “must have” and it becomes about quality of life for real people. This is digital inclusion. This is something you can’t unsee, you can’t unlearn, and you can’t ignore.

Making digital accessibility a priority — not a requirement

In my role as an accessibility trainer, I like to kick-off each session with the question: “What are you hoping to learn today about digital accessibility?” I ask this question to establish a rapport with the audience and to understand where everyone is in their accessibility journey, but I am also evaluating the level of company and individual buy-in too. There is nothing worse than showing up to teach a group that does not care to be taught. If I hear the words “I am only here because I have to be” — I know it will be an uphill battle to get them anywhere close to Stage 4: Understanding, so I mentally regroup and aim for another stage.

In my experience, when companies and their leaders say “Digital accessibility is a requirement,” nine times out of ten there is a motivating factor behind this sweeping declaration (for example, impending litigation, or at least the fear of it). When changes are framed as mandatory and packaged as directives from on high with little additional context, people can be resistant and will find excuses to fight or challenge the declaration, and any change can become an uphill battle. Calling something “mandatory” only speaks to Stage 1: Awareness.

By swapping out one word from the original declaration and saying “Digital accessibility is a priority,” companies and their leaders have reframed the conversation with their employees. When changes are framed as “working towards a solution” and discussed openly and collaboratively, people feel like they are part of the process and are more open to embracing change. In the long run, embracing change becomes part of a company’s culture and leads to innovation (and, yes, inclusion) on all levels. Calling something a priority speaks to Stage 4: Understanding.

Some of the excuses I often hear from clients for not prioritizing accessibility is that it is too difficult, too costly, and/or too time consuming — but is that really the case? In the same accessibility training, I lead an exercise where we look at a website with an accessibility testing tool and review any issues that came up. With the group’s help we plot out the “impact to user” versus the “remediation effort” on the part of the team. From group to group, while the plots are slightly different, one commonality is that close to 80% of the errors plotted fall into the quadrant of “simple to fix” for the team, but they also fall under “high impact” to the user. Based on this empirical data, I won’t buy the argument from clients who say that accessibility is too difficult and costly and time consuming anymore. It comes down to whether it’s a priority — for each individual and for the company as a whole.

What will your coding legacy be?

The infinite monkey theorem states that a monkey hitting keys at random on a typewriter for an infinite amount of time will eventually type any given text, such as the complete works of William Shakespeare. So by that same logic, a programmer hitting keys at random on a computer for an infinite amount of time will almost surely produce a website that is accessible. But where is the thought process? Where is the human element? While all the things we’ve already talked about — awareness, education, and prioritization of accessibility are important steps in making the digital world more inclusive to all — without intent, we are just going to keep randomly tapping away at our computers, repeating the same mistakes over and over again. The intent behind the code has to be part of the process, otherwise accessibility is just another task that has no meaning.

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

Because when you strip away all the styles, all the mark-up, all the cool features from a website or app — what’s left? People. And honestly, the more I learn about digital accessibility, the more I realize it’s not about the code at all. Digital accessibility is rooted in the user; and, while I (and countless others) can certainly teach you how to write accessible code, and build you tools, patterns, and libraries to use, I realize we can’t teach you to care. That is a choice you have to make yourself. So think for a moment — what are you leaving the next generation of developers with all that inaccessible code you haven’t given much thought to? Is it the coding legacy you really want to leave? I challenge you to do better for my daughter, her peers, and for the countless others who are not fully represented in the tech community today.

Imagine you’re ready to apply for your next job. Like most busy professionals, you probably haven’t updated your résumé or your portfolio since you looked for your current job. 

Now you need to update both, and you can’t remember what work you’ve done over the past few years. (In fact, you can barely remember what you’ve done over the past few months!)

So you scramble to update your résumé with new content. Then you spend all weekend scraping together a new portfolio using screenshots of whatever work evidence you can find on your laptop. You submit the résumé and portfolio with your application, hoping you didn’t forget to include any major career milestones you achieved over the last few years. 

This is the process most of us use to approach our job search. We wait until we’re ready to find a job, panic at our lack of résumé and portfolio, and pull together a “good enough” version of each for the job application. (Trust me, I’ve done this many times myself.)

This is a stressful and ineffective way to approach a job search. There’s a much better approach you can take—and you can start working on it now, even if you’re not on the job market.

The Career Management Document

A Career Management Document (CMD) is a comprehensive collection of your résumé and portfolio content. It’s a document you update regularly, over time, with all the work you’ve done. 

When you’re ready to apply for your next job, you’ll have all the résumé and portfolio pieces available in your CMD. All you need to do is assemble those pieces into résumé and portfolio documents, then send the documents off with your job application.

I update my CMD about once a week. I start by reviewing evidence of my recent work. I review Slack messages, Basecamp posts, emails, and any other current work-related content. I write my accomplishments in the format of résumé bullets, using the framework of responsibilities and accomplishments from this Manager Tools podcast. Then I add those bullets to the CMD. 

Here are some examples from my CMD:

• Coached a student on writing a stronger portfolio story to showcase their advanced UX skills, resulting in the student getting a job interview.
• Facilitated an end-of-study analysis in under 90 minutes to help the team synthesize user research data from 12 participants.
• Led a remote retrospective with teams in two offices, developed actionable takeaways, and ended on time despite a delayed start.

My CMD has several hundred résumé bullets, and it continues to grow. I organize content by year and by project. Within each project are responsibilities and accomplishments.

I add any content to the CMD that might go into my résumé someday. I include everything I can think of, even if it seems insignificant or trivial at the time. 

For example, I sometimes help with social media marketing at Center Centre, the UX design school where I’m a faculty member. I include it in my CMD. I don’t plan to pursue social media marketing as a career, but it may be relevant to a future job. Who knows—I may apply to work for an organization that makes social media marketing software someday. In that case, my social media experience could be relevant.

Include portfolio artifacts with your CMD

In addition to capturing bullets for my résumé, I capture content for my portfolio. Each week, I gather screenshots of my work, photos of me working with the team, and any other artifacts I can find. I store them in an organized system I can reference later. 

I also take brief notes about the work I did and store them with the artifacts. That way, if I look back at these materials a year from now, I’ll have notes about what I did during the project, reminding me of the details.

For example, after I facilitated a user research analysis session late last year, I captured evidence of it for my portfolio. I included photos of the whiteboard where I recorded public notes during the session. I also captured brief notes about who attended the session, the date, and when it took place during the project. 

You can use whatever tools you’d like to gather evidence of your work. I use Google Docs for the résumé portion of my CMD. I use Dropbox to store my portfolio artifacts. I create Dropbox folders with dates and project names that correspond to the contents of my CMD.

The key is to collect the evidence regularly and store it in an accessible, organized way that works for you. To know if you’re storing work evidence effectively, ask yourself, “Will I understand this CMD content a year from now based on how I’m capturing and storing it today?” If the answer is “yes,” you’re in good shape.

Update your CMD regularly

For the CMD to work when you need it, it needs to be comprehensive and up-to-date. As I mentioned before, I update my CMD once a week. I schedule thirty minutes on my calendar each week so I remember to do it. 

Sometimes I have a busy week, and I can’t spend thirty minutes on my CMD. So I spend whatever amount of time I have. Some weeks, I only spend ten minutes. Ten minutes per week is better than zero minutes per week. 

Occasionally, I don’t get a chance to update it because my week is so hectic. That’s OK because I’ll probably get to it the following week. 

I recommend updating your CMD once a week and not once a month or once a quarter. If you wait even a month, you’ll have trouble remembering what you did three and a half weeks ago. Even worse, if you schedule a CMD update once a month and then miss it, you won’t get to it until the next month. That means you have to think back and remember two months of work, which is hard to do. 

Updating your CMD every week, while the work is fresh in your mind, gets the best results.

The CMD benefits you in additional ways

The CMD can help you prepare for your job search beyond your résumé and your portfolio. 

You can use it to prepare for a job interview. Since you’re capturing work evidence from each stage of the process in your CMD, you can use that evidence to remember what you did throughout a project. Then, you can craft a story about your role on that project. 

Hiring managers love to hear stories about your work during job interviews. For instance, if you’re a designer, they want to know the journey you took during your design process, from the start of a project to the end. A detailed CMD will help you remember this process so you can share it in an interview. 

I’ve even used my CMD to write blog posts. I’ve been blogging regularly for the past two years, and I often refer to my CMD to remember work experience I had that’s relevant to what I’m writing. When I wrote the article “How to Tell Compelling Stories During a UX Job Interview,” I used my CMD to remember interview preparation exercises I did with students. 

The CMD can also help you track work accomplishments for your quarterly or annual performance reviews. Additionally, you can use it to write job ads when hiring for related roles on your team.

Lastly, I find it rewarding to peruse my CMD now and then, especially when I look back at work I did over a year ago. The CMD serves as a record of all my professional accomplishments. This record helps me appreciate my professional growth because I see how far my skills have come over time.

Learn more about the CMD from Manager Tools

At Center Centre, we originally learned about the Career Management Document through the Manager Tools podcast series.

Manager Tools’ podcasts explain how to use a CMD for your résumé. We expanded their approach to include portfolio work as well. I recommend listening to their podcasts about creating and maintaining your CMD:

• Systematic Career Documentation (Part 1)
• Systematic Career Documentation (Part 2)

Prepare for your next job search now

We tell our students at Center Centre that preparing for your next job search is a process that starts early. It’s like saving for retirement—the sooner you start saving money, the more likely you are to be prepared when the time comes. 

Similarly, collecting résumé and portfolio content ahead of time will prepare you to find your next job whenever you’re ready to do so. It also prepares you for a sudden job termination like an unexpected layoff. If you lose your job without warning, you’ll likely be under a lot of stress to find a new position. Having a CMD ready will relieve the additional stress of building a résumé and portfolio from scratch. 

If you don’t have a CMD yet, now is a great time to start one. Schedule 30 minutes this week to begin crafting your repository of work accomplishments. You’ll be glad you did when you seek your next job.

In this chapter, you’ll learn about these plays:

• How to create a jobs-driven roadmap
• Using job stories to solve specific design problems
• How to architect the structure of a solution
• Testing assumptions directed by JTBD

A software company I once worked for held what were called “hackweeks” once a quarter. This was a time for developers to work on “whatever they wanted,” as it was framed. Give engineers time to play around with technology, and they’re bound to find the next innovation, or so the theory went.

Hackweek was a big deal for us. Dozens of people organized it, and every developer in the company stopped work to contribute to the effort. It was costly, but we were committed to hackweek. After all, new software offerings come from new development, right?

Here’s how it went: small teams formed to cobble together starter projects representing the use of some new technology. At the end of the week, a panel judged the dozens of concepts that emerged, and the winning “solutions” were rewarded.

But in our case, hackweek was like shooting a shotgun in the wrong direction while blindfolded and hoping to hit the target. The result was inevitably a collection of concepts looking for a problem to solve. It was innovation theater at its best.

To be fair, not all hackathons are bad. Some organizations coordinate hackathons with strategic imperatives or with customer needs. And sure, it’s also good to flex creative muscles and practice collaboration across teams. But given their cost and imprecision, hackathons are often largely ineffective in producing usable concepts.

The problem is not a lack of ideas—companies are usually swimming in them. Like ours, many organizations have a Darwinistic outlook on innovation: generate more and more ideas, and the best will surely rise to the top. Said another way, when looking for a needle in a haystack, the best approach is rarely to add more hay.

The problem is knowing which ideas to pursue. The goal of innovation activities shouldn’t be to collect as many ideas as possible, but instead to get to the right ideas—the ones that matter most to the people you serve.

But more than that, the real challenge is in overcoming the natural forces in organizations that keep good ideas down. Chief among these is uncertainty, a leading deterrent to innovation. New ideas are a gamble for risk-averse managers, even if well-expressed in a high-fidelity prototype.

JTBD provides a way to increase your chances of success by first identifying the right problem to solve. Then JTBD gives you decision-making criteria for moving forward: bet on solutions that address unmet needs to create profitable differentiation.

Focus first on getting the main job done for the individual and fulfilling their needs in relation to the job. From this perspective, hackathons and other idea-generating efforts can be framed by JTBD as both inputs and outputs in terms of how concepts are evaluated.

After understanding the job landscape and defining the value you’re going after, you can continue using JTBD thinking to align teams around the design of your solution. Create a roadmap based on your JTBD landscape to set a common direction. Then use job stories to get everyone on the same page and tie local design efforts to the big picture and to architect the solution structure. JTBD can also guide the experiments you conduct to test your team’s assumptions.

Create a Development Roadmap

At its highest level, a roadmap is a sequence of development events—the relative chronological order in which features and capabilities will be built. Roadmaps serve as a central point of reference for teams to align their efforts. They show the path forward without defining individual tasks.

In the age of Agile and Lean efforts, roadmaps have gotten a bad reputation. People are quick to point out—and rightfully so—that long-term plans inevitably fail: priorities change, unforeseen challenges arise, and timelines slip. The solution, they might argue, is to have no long-term plans and to work on short initiatives with the flexibility to change as needed.

But while providing decision-making power to local development teams makes sense, overall alignment is still needed. An alternative way of viewing roadmaps is to see them not as a definitive project plan, but as a vision of how you’ll create an offering that customers will value. Roadmaps are not unchanging predictions of future activity, but a way to provide transparency for the sequence of steps your team will take to design solutions.

The information in a roadmap helps the entire organization get aligned, not just developers. It’s a strategic communication tool reflecting intention and direction. More importantly, road mapping isn’t just about the artifact: it’s about getting a common understanding of where you’re headed. In this sense, the roadmap occupies the space between the vision and detailed project planning.

JTBD can help create roadmaps that focus on the value that the organization intends to create and deliver for customers. The trick is to get the right problem to solve. Use the insights from your JTBD investigation to formulate roadmaps that are grounded in real customer need.

Mapping the Road Ahead

For a concrete approach to road mapping, I recommend the book Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Conners.^[1] In it, the authors clearly articulate the steps to creating meaningful product roadmaps.

JTBD plays a key role in aligning to customer needs, as the authors write: “We recommend starting with the chunks of value you intend to deliver that will build up over time to accomplish your visions. Often this is a set of high-level customer needs, problems, or jobs to be done.”

Their approach breaks down the four key elements of a good product roadmap:

• Product vision: The vision outlines how your customers will benefit from your offering. How will the job performer benefit from the solution? What will getting the job done look like after the solution is in place?
• Business objectives: A roadmap must be aligned with the organization’s strategy and objectives. The goals of the business are important for measuring progress.
• Timefames: Rather than committing to specific dates, good roadmaps sequence work and set broad timelines for completion.
• Themes: These are the key problems that customers face when completing a job, or clusters of needs that align to the overall solution to be created. JTBD helps frame the themes of your roadmap in particular.

Figure 5.1 shows an example from their book of a basic roadmap overview for a fictional company, The Wombatter Hose, illustrating these main components. Note the disclaimer, as well, indicating that the roadmap is subject to change.

Putting it all together, the process for creating a JTBD-driven roadmap can be broken down into four phases.

Step 1: Define the solution direction.

Define the various elements of your overall product strategy to get agreement on how you’ll be using them. In addition to your solution vision, also define the following together with the team:

• Mission: What are your business intentions? The mission is about what your organization wants to ultimately achieve.
• Values: What are your beliefs and ideals? What is the philosophy of your organization and solution? Values define the philosophy of the team and what it believes.
• Business objectives: What are the specific goals your offerings will accomplish for the organization? Frame these in terms of outcomes, not outputs.

Step 2: Determine customer needs to pursue.

Next, decide on the customer needs to pursue. Here, the authors of Product Roadmaps Relaunched stress the importance of grounding the roadmap in actual customer need. JTBD is central to this step. They write:

“Identifying customer needs is the most important aspect of your roadmapping process. Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.”

As outlined in Chapter 2, “Core Concepts of JTBD,” needs are hierarchical—from high-level aspirations to main jobs and sub-jobs to micro-jobs. Figure out the top-level jobs to explore and then drill down into the specific themes to target.

The “value themes,” as they are called, might come right from the job map. Locate the areas of highest underserved needs and use those stages as the categories of your roadmap themes. Or you can cluster needs to form themes that don’t necessarily follow the chronology of the job map. The important point is to ground the division of the roadmap in real-world observations of the customer’s job to be done and align the timeline to it.

Step 3: Set a timeline.

Next, create a sequence of value themes that your team will work toward. Timelines can be absolute, relative, or a mix of both. Absolute timelines with specific dates carry the risk of changing, which, in turn, can cause confusion or missed expectations.

Relative timelines give more flexibility but still provide insight into what’s coming and why. There are various terms to use, but the timeline is often broken into three phases for near-term, mid-term, and long-term. Examples include “now, later, future” or “going, next, later” or something similar. Find what works best for you.

Step 4: Align development effort to the roadmap.

Finally, conceptualize specific solutions to design and create. Use job stories to tie the overall project intent to customer needs, outlined in the next section. Then conceptualize solutions around getting the entire job done or the parts of it determined to be most strategically relevant to your business.

After a roadmap is created, you may then need detailed project plans to track progress. A simple Kanban board can serve that purpose in many cases. Or, for more complex software development efforts, tracking software may be needed. In Agile efforts, epic planning and then sprint planning come after you have an overall roadmap.

Tying the overall plan to customer needs gives the design and development teams the feeling that they are building something that matters to customers. Staying focused on customer needs helps avoid building things your customers don’t want. The nature of a job stays the same, even as features may shift. Grounding the roadmap in JTBD ensures that both its longevity and ability to absorb will change.

Learn More About This Play

Lombardo, C. Todd, Bruce McCarthy, Evan Ryan, and Michael Conners.^[3] Product Roadmaps Relaunched. Sebastopol, CA:O’Reilly, 2018.

This book distills a wealth of practical information into a compact guide on roadmapping. The authors go to great lengths to provide numerous examples and stories from real-world cases. They use a realistic, modern approach for creating a roadmap that is driven, in part, by JTBD.

Align Teams to Job Stories

Agile development enables teams and organizations to work in a flexible way. The approach started in software development, but has spread to other domains, including government and the military. The principles of Agile development can apply to just about any field.

A key part of Agile is to break down efforts into individual units of work. User stories are short descriptions of features and functionality written from the perspective of the end user. Teams can focus on only a small part of the whole and make progress in a controlled way.

User stories are commonly written in a three-part format. The first element indicates a user’s role in the system. The second points to a capability that enables the person to get a task done. The last part often describes a benefit or reason for using the capability.

Although specific styles can vary, a typical user story resembles something like the following:

As a <role> I can <capability>, so that <benefit>

Examples of use stories in this format include:

• As a system admin, I can specify files or folders to back up based on file size, date created, and date modified.
• As a user, I can indicate folders not to back up so that my drive isn't filled up with things I don't need to be saved.
• As a user, I want to update the name of a document so that I can categorize it.

For any given system, there may be hundreds of user stories. Some can be quite granular, such as describing a single button and why a user would click it. Stories are then organized into a backlog or repository of functionality to be built. Teams break off logical groups of user stories in sprints or two- to four-week cycles of work.

Job Stories

Although user stories are good for breaking down work, they typically fail to connect the solution being built with user needs. They lack an indication of why someone would behave in a certain way and what they need to get a job done. In fact, often user stories are derived from the capability being built, not from observing actual behavior.

Job stories are an alternative to user stories. They follow the tradition of breaking down efforts into smaller pieces, but through the JTBD lens. The technique was first pioneered by the product development team at Intercom, a leading marketing communications solution. They wanted to avoid leading designers with a preconceived solution, as well as tying development to the company vision and strategy.

Paul Adams, an Intercom product manager, wrote about job stories for the first time, saying: “We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome.”^[4]

As a result, their job story format also has three parts. But instead of focusing on a generic role, like a “user” or an “admin,” job stories begin with a highlight on the situation and context, not the individual:

When [situation], I want to [motivation], so I can [expected outcome].

Examples of job stories include:

• When an important new customer signs up, I want to be notified so that I can start a conversation with that person.
• When I visit someone’s profile page, I want to see how many posts they have in each topic so that I have an understanding of where they have the most knowledge.
• When I have used the application multiple times, I get nudged to contribute so that I am encouraged to participate.

JTBD author and leader Alan Klement has done the most work refining the job story format.^[5] He believes that adding more information about the circumstances shows causality better. Focusing on the context shifts attention from a persona to the situation. Klement advises that you avoid writing vague situations, but instead be as specific as possible.

For instance, consider these three possible situations for the first element of job stories:

• When I’m hungry…
• When I’m lost…
• When I want to check my email…

Instead, Klement recommends describing the circumstances in rich detail:

• When I’m hungry, running late to get somewhere, not sure when I’m going to eat again, and worried that I’ll soon be tired and irritable from hunger…
• When I’m lost in a city that I’ve never been to, don’t know the local language, and am worried that I’ll be wasting my time in places I don’t want to be in…
• When I want to check my email, but don’t want anyone around me to know I’m checking my email because they’ll think I’m being rude…

Each of these example situations provides more context for designing an appropriate solution.

Working with Job Stories

Job stories are modular, giving designers and developers the flexibility to solve problems in alternative ways. Job stories are grounded in real-world insight, and they are more powerful than user stories in guiding solutions. But creating job stories is more free-form than other JTBD techniques. Still, there are patterns that you can follow. Using the elements from Chapter 2, I suggest the following structure for job stories:

When I [circumstance + job stage/step], I want to [micro-job], so I can [need].

Examples:

• When I am one of the top posters while updating my social media feeds daily, I want it to show on my profile so that I can increase recognition as an expert on the subject.
• When I run out of materials needed while completing an art project, I want to find alternative materials so that I can maximize the number of uses of my current supplies.
• When preparing for my commute and running late, I want to know the current weather along my journey so that I can minimize the chance of arriving wet.

Consider the last example. The first element combines information about the circumstances (running late) of getting the main job done (commute to work) within a stage of the process (prepare for commute).

The second element points to an even smaller step or micro-job (check forecast). It should be formulated without reference to specific technology, but should be specific enough for designers and developers to create a specific capability.

Finally, the last element can be taken right from your list of needs. In this case, the job performer (commuter) wants to avoid showing up to the office wet (minimize the chance of arriving at work wet). You can leverage the elements your JTBD landscape already uncovered in research directly in the formulation of the job story statements.

In researching this book, I’ve come across various alternative approaches to formulating job stories. Andrea Hill, a prominent advocate of JTBD on social media, suggests a slightly different approach. She sees the middle element pointing directly to a feature or solution of some kind, thus explicitly crossing from the problem space into the solution space. Her basic format is as follows:

When I [circumstance], I want to [solution capability], so I can [need].

A job story for the previous example of commuting to work might then look like this:

When I’m preparing to commute to work, I want to have weather forecast notifications pushed to my phone, so I can minimize the chance of arriving wet.

Steph Troeph, research and JTBD instructor in the UK, approaches job stories in yet another way. She thinks of them with this formula:

When I [circumstance], I want to [job], so that [benefit a solution offers].

Regardless of your interpretation, the key is to find a consistent structure and stick with it. The form you end up with needs to be appropriate to your team and your situation.

Jobs Stories in Action

Ultimately, job stories tie a local design and development effort to a broader JTBD framework. Because the format of job stories includes contextual details, they are portable. In other words, a job story should make sense without having to know the larger JTBD landscape or job map. As a result, job stories have a more “plug-and-play” versatility that is often required for Agile designs and development teams.

For instance, Agile planners can manage a backlog of job stories much in the same way that they would manage user stories. If a given sprint gets slowed down or changes direction, stories not addressed can be carried over to the next sprint. Having a smaller, self-contained description of the smaller job to be done has advantages during the design and development phases.

But to be clear: I have found that job stories typically do not replace user stories for development completely. Instead, job stories guide and frame the conceptualization of a solution rather than track implementation. They serve best as a design tool to create or determine concept direction and design. Developers and engineers will likely still need user stories to measure the burndown rate and overall progress.

Your job map provides an overall orientation to your JTBD landscape and allows you to zero in on a specific area for design and development. A roadmap gives you a high-level sequence of development with the rationale for planning activities. Job stories are more specific and guide the local design and development of features and capabilities.

Follow these steps to create job stories based on your JTBD research:

Step 1: Understand job stages and circumstances.

Base the relevant jobs and circumstances on previous interviews and observations. For each area of development in your solution, consider the steps in the main job. Then drill down and list the smaller and smaller steps as micro-jobs, using the rules of formulating JTBD. Also identify the circumstances that apply to that part of the main job in particular.

Depending on the depth of your prior research and how well you and your team understand the job, you may not need to do more research to create and validate job stories. It’s never a bad idea to speak with people again and drill down on specific problems and objectives they have. During additional interviews, ask “how?” until you get more granular in understanding of subgoals and objectives.

Step 2: Formulate job stories.

As a team, write job stories that are specific to your design and development effort. Decide on a consistent format for the job stories and stick to it.

Strive to come up with unique, mutually exclusive stories that target specific jobs and circumstances. Avoid redundancy. For instance, in the previous example, you probably don’t need separate stories for commuting by train versus commuting by car. Develop the job stories that matter the most and focus on a limited set. You may end up with anywhere from three to eight job stories per project or sprint.

Step 3: Solve for the job stories.

Make job stories visible and transparent to the entire team to solve for the job stories. For instance, post a relevant list of job stories in a brainstorming session for everyone to see. Or list job stories at the beginning of a design critique so that the team has context for making comments. Use JTBD to guide design and development decisions.

It’s also possible to then use the job stories to review the appropriateness of your solutions. First, the design team can use the job stories relevant to a project as heuristics. They should constantly ask if their designs are meeting the user’s goals set out in the job stories.

Then you can test solutions with users against the job stories. Show users your solutions (e.g., as a mock-up or prototype) and ask them how well each addresses the job stories. This can be done in an interview-style fashion or with a survey. The job stories ultimately become a measure for success of the designs before anything is built.

Job stories let you take a step back and look at the context of the job while designing a product or service. In this respect, job stories fill an important gap between the observations of customers and solution development, connecting insights into customer needs to individual features and development efforts.

Related Approaches: Needs Statements

Design thinking is a broad framework for creative problem solving. It is rooted in human-centered methods that seek to develop deep empathy for people and then to devise solutions that meet their needs. In design thinking, it is important to define the problem to solve before generating options for solutions.

One technique to encapsulate insights from research is to generate need statements, greatly resembling job stories in form. But these statements differ from “needs,” as defined in Chapter 2, in that need statements in design thinking are not specifically limited to the outcomes of a getting a main job done, and they can be aspirational in nature.

Need statements in design thinking also tend to be much more focused on a persona or an individual rather than the circumstances. For instance, writing for the Norman Nielsen Group, Sarah Gibbons refers to need statements representing a point-of-view for the user of a system:^[6] “A user need statement is an actionable problem statement used to summarize who a particular user is, the user’s need, and why the need is important to that user.”

Like job stories, need statements have three components: a user, a need, and a goal. The user corresponds to a goal-based persona based on research (as outlined in Chapter 4, “Defining Value”). A need is expressed independent of a feature or technology. The goal is the result of meeting the need. Gibbons provides an example:

Alieda, a multitasking, tech-savvy mother of two, needs to quickly and confidently compare options without leaving her comfort zone in order to spend more time doing the things that really matter.

Note that the insight at the end of this statement, “doing the things that really matter,” is very broad and hard to measure. Job stories, on the other hand, favor a more specific context and outcome. For instance, rewriting the above example through the lens of job stories might yield something like the following:

When I’m multitasking and in a rush, I need a familiar way to quickly and confidently compare options so that I can minimize the time spent on finding a solution.

Like need statements in design thinking, job stories also avoid the mention of features or technology. Yet, they are much more specific to a given job and its context. While both a need statement from design thinking and a job story can feed into the creative generation of solutions, job stories will provide more direct guidance without prescribing a solution.

But the definition of a need in design thinking can vary greatly. For instance, IBM’s Enterprise Design Thinking approach also includes guidelines for generating statements.^[7] Not surprisingly, there are three parts: a user, a need, and a benefit. Here’s an example from the IBM site:

A developer needs a way to make sense of minimal design so that they can prototype faster.

This example is much more specific than Gibbon’s approach, yet still avoids mentioning a specific solution. There are no aspirational elements, such as “pursuing lifelong dreams,” sometimes found elsewhere in design thinking. IBM’s approach to need statements is closer to the job story approach, but is also light on describing the circumstances of use.

In some sense, the differences between job stories—even with the variations in format—and need statements points to a key distinction between JTBD and design thinking. The former focuses much more on the circumstances than the person’s state of mind or psychology. Where design thinking seeks to gain empathy for the individual as a starting point, JTBD seeks to understand the circumstances of accomplishing an objective before factoring in emotional and personal aspects.

Learn More About This Play

Klement, Alan. “Replacing the User Story with the Job Story.” JTBD.info (2013); “5 Tips for Writing a Job Story,” JTBD.info (2013); “Designing Features Using Job Stories,” Inside Intercom (2015).

Klement has done the most extensive work to develop the job story technique. These three articles outline the basis for creating them. The technique has evolved slightly, but Klement points clearly to how he’s updated his approach. Klement and others have posted widely about their use for development efforts, but start with these resources.

van de Keuken, Maxim. “Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering.” Thesis, Utrecht University, 2017.

This thesis project offers a detailed investigation of how job stories are applied to date. After illustrating the history of job stories, Van de Keuken presents the results of his original research variations in application of job stories as seen in practice. This work contributes greatly to making job stories a more formal part of software requirements engineering.

For a happy pregnancy: Coimbatore Parenting Network rings in Mother’s Day with a two-day online session on pregnancy, raising babies, and making informed birthing choices

Nagaland Cong ready to pay train fare of migrant workers

One trampled to death by domestic elephant

Assam students in Andhra, Telengana urge govt to bring them back home

Online training being imparted to librarians

SGBG seeks steps to stop corona spread from red zones

CM invites companies to set up ventures in State

COVID-19 recovery rate in India improves to 29 pc

16 migrant workers crushed to death by goods train

30 new COVID-19 cases in Tripura, total rises to 118

35 students in Assam begin journey back home to Madhya Pradesh, Chhattisgarh

Washington, DC : American Chemical Society, [2018]

Berlin ; New York : Springer-Verlag, [2005]

New York : Springer, [2006]

Preaching Today provides pastors and preachers sermon prep help with sermon illustrations, sermons, sermon ideas, and preaching articles.

Preaching with heart: A case for emotion in expository preaching.

Six flights flew in from five countries on Friday. Passengers returned from Singapore, Dhaka, Bahrain, Riyadh and Dubai to Delhi, Srinagar, Kochi, Kozhikode and Chennai

A majority of H-1B employers, including major American technology firms like Facebook, Google, Apple and Microsoft, use the programme to pay migrant workers well below market wages, a new report has claimed. 60 per cent of H-1B positions certified by the US Department of Labor are assigned wage levels well below the local median wage for the occupation, the report found.

Gilead Sciences Inc said on Tuesday it was in discussions with chemical and drug manufacturers to produce its experimental COVID-19 drug remdesivir for Europe, Asia and the developing world through at least 2022.

French drugmaker Sanofi SA said it plans to enroll thousands of subjects globally for trials of an experimental vaccine for the coronavirus it is developing with GlaxoSmithKline Plc, and that it has started to discuss advanced purchases with several countries. Sanofi teamed with British rival GSK to come up with a candidate it hopes will be ready next year.

Tesla chief Elon Musk said that he was "selling almost all physical possessions" and would no longer own a home and would devote himself to Mars and Earth.

Uber will cut about 3,700 full-time jobs and CEO Dara Khosrowshahi will forgo his base salary for the remainder of the year, the company said on Wednesday, as the Covid-19 pandemic decimates its ride-hailing business. Layoffs included its customer support and recruiting teams and expect to incur about $20 million in costs for severance and related charges.

In a major development, the Trump administration has urged a federal district court not to block an Obama-era rule allowing certain categories of spouses of H-1B visa holders to work in the United States. This move, for now, provides a breather to the estimated one lakh plus Indian-spouses of H-1B workers who hold an employment authorisation document.

The economic catastrophe caused by the viral outbreak likely sent the US unemployment rate in April to its highest level since the Great Depression and caused a record-shattering loss of jobs. The unemployment rate likely jumped to at least 16% — from just 4.4% in March — and employers cut a stunning 21 million or more jobs in April.

Facebook Inc said on Friday it would allow its workers who are able to work remotely to do so until the end of the year as the coronavirus pandemic forces governments to extend stay-at-home orders to curb the spread of the disease. The social media giant also expects most offices to stay closed until July 6, according to a company spokesperson.

Lufthansa Group on Friday announced that Lufthansa, Eurowings and SWISS will be starting June offer monthly restart schedules to significantly more destinations in Germany and Europe than in the past few weeks. The repatriation schedules will end on May 31.

Boxscore News reviews Blanton’s Browns: The Great 1965–69 Cleveland Browns by Roger Gordon. “[Blanton's Browns] casts a brilliant beam on a highly competitive NFL outfit. During this era,’65-’69, the franchise nearly repeated as league title holders, nabbed 3 Division championship, and missed by a game going to a Super Bowl.” Read more… Find out more about Blanton’s Browns  

Professors Allen Hurlbert and Keith Sockman want their students out of the classroom as much as possible. Every other year, the UNC researchers lead an avian biology course that explores the physiology, anatomy, evolution, and behavior of birds. Throughout the semester, the class visits wildlife reserves across the state to see these lessons in the field.

Papermaking

Angus of Dunbarney Primary School wins iPad

Isobel Mair School wins iPads

Kingussie High School student announced as overall winner of Photo14

Online retailers such as Myntra and Tjori have their consumer engagement teams working on to engage their customers till the time the lockdown eases. Others such as fashion brand Anita Dongre are brainstorming changes in consumer behaviour and how to keep them engaged online till the time stores become fully operational.