We've made no secret of our dislike for the typical startup-takes-venture-capital storyline and culture. Maxwell Wessel at The Harvard Business Review just about codifies what repels us about it:

Raising venture capital isn’t the be all and end all of entrepreneurial success. But it is an important metric... for an important subset of the business world — firms in pursuit of explosive growth — raising capital from angel investors or venture capitalists is an early step on a long and uncertain road to success.

So, firms in pursuit of explosive growth that raise capital to fund a long and uncertain roadtrip to success are an important subset of the business world.

If you judge entrepreneurial success as surviving or selling (including raising follow-on funding, being bought, or successfully IPO’ing) as no doubt your investors do, then your odds of success are lower outside of the superhubs.

What if you judge it by something meaningful, like building something that makes your customers' lives better?

Every business is unique, so I would never claim to have the perfect answer for any founder trying to select his or her location. It’s not that founders outside of superhubs work any less hard, are any less talented, or have worse ideas. The reason the numbers look the way they do is because the environments are fundamentally different in start-up superhubs. And until community members acknowledge the shortcomings of secondary markets, and come up with some way of addressing them, then we should be open and honest with our entrepreneurs about the heavy toll they will pay to build their businesses where they live today.

The heavy toll we pay here: we're home for supper every night; our wives, children, and friends know and love us; every customer is important to us; no one's forcing us into ill-advised moonshots; we spend a good 25% of any given workday laughing together; we don't spend our days making money for someone else.

Ah, the high cost of not moving to Silicon Valley to change Populi into something that won't be here in five years.

We just updated our Privacy Policy.

Previously, Section 8 (our policy towards children) included a blanket statement indicating that we do not collect information about children under 13—and that if we inadvertently did, we would delete it. However, we realized that this statement went a little too far for our customers. Many of you actually do keep records of children under 13—whether as relatives of faculty or staff, as prospects, and sometimes even as students. Not wanting to commit ourselves to deleting customer data that you're allowed to collect, we wanted to clarify the policy regarding information about children under 13.

So, the long and the short of it is that...

• It's our responsibility to delete information about children under 13 that we may take in through this site (populi.co).
• It's your responsibility to take all appropriate precautions with such information that you manage through your school's populiweb site.

If you have any questions about any of this, please don't hesitate to contact us.

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.

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.

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.

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.

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:

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.

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.