Alan Klement: Replacing the user story with the job story

Expanding on Brendan's post about designing for the “job to be done” rather than starting with a visual design, Alan Klement introduces us to the idea of using "Job Stories" instead of "User Stories":

Summed up, the problem with user stories is that it's too many assumptions and doesn't acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there's no room to ask 'why' - you're essentially locked into a particular sequence with no context.

The distinction may seem subtle at first, but it's easy to make the mistake of designing a particular interface or workflow to meet the needs of one specific “user”, when it will actually be used by different people in different roles seeking different ends. Writing a story about the job someone wants to do—rather than assuming what kind of user they are—should lead to designs that work better in the real world.

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

We've seen something like this at work in our Feature Request Forum. Users suggest features based on their own particular user stories (nothing wrong with that). But it's not until other users pile on with their own suggestions (and user stories) that the job story emerges. We've found that it often takes multiple perspectives on the problem for us to identify the job to be done.

"Include unfinalized courses" toggle on the students table

Now available on the Students table: the "Include unfinalized courses" toggle. When checked, it factors in-progress grades from your students' unfinalized courses into the Term GPA, Cumulative Units, and Cumulative GPA columns. When unchecked, it backs unfinalized information out of those columns, giving you the same figures formerly available only on individual transcripts.

9-25-13 No show unfinalized

9-25-13 Show unfinalized

Over the years we've tuned the Students Table to show as much real-time information as we could—thus, Cumulative GPA factored in student performance in unfinalized courses. But some users informed us that they also need the Table to give them snapshots of where the students were starting from in a given term... so that unfinalized info was getting in their way.

Thus, the toggle. Now you can get two perspectives on all your current students with a single click.

The job to be done

Inside Intercom's The Dribbblisation of Design lambastes software designers who start with the visual design of their program without first considering the underlying layers of a well-built app.

Much of the product design work from job applicants I’ve seen recently has been superficial, created with one eye towards Dribbble [an online design community]. Things that look great but don’t work well. Perfect pixel executions of flat design, but work that doesn’t address real business goals, solve real problems people have every day, or take a full business ecosystem into consideration.

The best software design starts with the unglamorous stuff: what is the user trying to accomplish? How can the software help them do that? How can the software explain how it works to the user?

This way of thinking owes much to Clayton Christensen, a Harvard Business School professor whose ideas on management and business are summarized in his "Job To Be Done" framework.  JTBD leads with this question: what job is the user hiring this product/service to do? It has a surprising range of applications—software, household products... and even milkshakes. And there's no doubt that it has plenty of uses in designing college management software.

Release notes: sequential payment numbers, aging report, and more

Sequential payment numbers

Transactions have them. Invoices have them. And now payments have them: sequential payment numbers. Every payment in your system now has a sequential number based on the order in which it was entered.

In the past we referred to payments solely by their receipt number—random alphanumerical strings like #4d5c6ce05a71a, #8b8x2nn092l3, or our personal favorite, #56oc092ma27z. But keeping track of payments like that is something better suited to computers than people. Thus, the change.

We ran a script to give every payment in your records a sequential number, starting from #1. And from here on out every new payment gets the next number in line. You can still find receipt numbers on the end of the online receipt URL shown on a given payment:

Screen-Shot-2013-09-20-at-2.51.50-PM1

Additionally, the Financial search now checks both payment and receipt numbers, so historic receipts are still easy to look up. If you have configured a custom receipt template, contact Populi customer support to have us replace the receipt number with the new payment number.

Aging report

In July we released an Aging Report. You can find it in Billing > Reporting > Aging. It shows all of your students' unpaid invoices and how long ago you billed them, together with information about pending financial aid and last payment received.

Aging Report

Time tracking in courses

A new tool in Course > Reporting shows how much time your students spent in your courses on a given date.

Email bounce & spam notifications

Awhile back we released a "deliverability problem" status for email addresses. The status was triggered when email was returned as undeliverable to that address or marked as spam. Now we notify you (via automated email) when you send an email that returns a bounce or spam report.

Release notes

These are some of the highlights from the past few months of releases, which has seen a steady trickle of incremental improvements to Populi. Complete release notes are compiled on a weekly basis in our Release Notes forum, so make sure to keep an eye on that to see what we put out there.

Terms of Service: we believe they're good for everyone

Prospective customers sometimes ask us to sign papers that would—whether instead of or alongside our own legal documents—govern our business relationship with them. Schools with the cash to have lawyers draft stuff for them are lucrative prospects, and we should be happy sign whatever if it'll bring them aboard.

But we decline to sign every single time.*

Why? What could Isaac's signature on another piece of paper do to our business?

The answer is, We don't know. Some of these documents outsize our own by an order of magnitude. They're written by lawyers working in other states. They contradict or negate our own Terms. They oblige us to requirements totally foreign to college software. For all we know, they could cripple the way we do business, and so make things sticky for all the rest of our customers.

They're just full of potentially expensive unknowns.

We do know this: our relationship with that customer would be very different from what we enjoy with everyone else. And that's just not worth it for anyone.

The Terms of Service define our relationship with our customers, and we want that to be a relationship of trust, adaptability, and common sense. The Terms protect both Populi—our property, employees, and business—and our customers: your data, your rights, and your enjoyment of the service. They permit our ongoing release of new updates that improve the value of the service. They let us update the Terms so no one is bound to what worked in 2008 but doesn't in 2013. And they give us the leeway to not enforce the Terms in a given situation—because we wanted the right to not be hardnoses about everything.

But it's not just the relationship that's valuable. It's also the fact that the relationship is the same for everyone: every school and every user is on the same footing as every other school and user. We cherish that. It's simpler in terms of administration—managing different agreements with different customers just doesn't scale. It's simpler in terms of knowing what to do when situations arise—support issues, pricing questions, data challenges. And it's simpler in terms of development—we're not bound to develop Populi to satisfy the requirements of someone's unique contract.

In a nutshell, we like the Terms of Service because we like the relationship they foster between us and our customers.

And that's why you won't catch Isaac's signature on some other piece of paper. Trust, adaptability, and common sense are just too valuable to this relationship.

* Do pardon the rhyme.

The Washington Post on "Maximizing Shareholder Value"

Steven Pearlstein writing for the Washington Post in "How the cult of shareholder value wrecked American business":

In the recent history of management ideas, few have had a more profound — or pernicious — effect than the one that says corporations should be run in a manner that “maximizes shareholder value.”

Indeed, you could argue that much of what Americans perceive to be wrong with the economy these days — the slow growth and rising inequality; the recurring scandals; the wild swings from boom to bust; the inadequate investment in R&D, worker training and public goods — has its roots in this ideology.

The funny thing is that this supposed imperative to “maximize” a company’s share price has no foundation in history or in law.

The focus on "shareholder value" effectively replaced long-term thinking with an obsession over short-term gains—and reconfigured the the structure of American business around that:

This infrastructure includes business schools that indoctrinate students with the shareholder-first ideology and equip them with tools to manipulate quarterly earnings and short-term share prices.

It includes corporate lawyers who reflexively advise against any action that might lower the share price and invite shareholder lawsuits, however frivolous.

It includes a Wall Street establishment that is thoroughly fixated on quarterly earnings, quarterly investment returns and short-term trading.

And most of all, it is reinforced by gluttonous pay packages for top executives that are tied to the short-term performance of the company stock.

A related article provides a case study: IBM, which through layoffs and outsourcing (among other things), has maximized shareholder value at the expense of the people and communities that once depended on it:

The main street, once swarming with International Business Machines employees in their signature white shirts and dark suits, is dotted with empty storefronts. During the 1980s, there were 10,000 IBM workers in Endicott. Now, after years of layoffs and jobs shipped overseas, about 700 employees are left.

Investors in IBM’s shares, by contrast, have fared much better. IBM makes up the biggest portion of the benchmark Dow Jones industrial average and has helped drive that index to record highs. Someone who spent about $16,000 buying 1,000 shares of IBM in 1980 would now be sitting on more than $400,000 worth of stock, a 25-fold return.

The software startup industry is deeply afflicted by this mindset: the shareholders whose value most startups are designed to maximize are known as venture capitalists.

As we've said before, we have no interest in maximizing shareholder value. We're in it to make life better for our customers, families, and employees.