Feb 9, 2015

Lending Club Borrower Accelerated Payment Teardown

Lending Club

The Lending Club is a peer-to-peer lending juggernaut. It is "the world’s largest online marketplace connecting borrowers and investors." The company recently went public (December 2014).

Earlier, I wrote about a key competitor: Prosper.com, and its 1-click borrow flow.


Let's say you're a borrower with a $4,000, 36-month term loan on Lending Club. Your monthly payment is $130.47 (Figure 1).

Figure 1

Problem Summary

What happens if you want to pay off your loan faster, or wonder what happens if you change the monthly loan payment amount? How would you approach this problem as a product manager?

Possible Solutions

First of all, as a product manager, your job is not to do the user-interface (UI) design work.  You have design experts who would be insulted if you thought you could do their work for them.

Rather, your role as a product manager is to explain what the goal of the feature is: explain the benefit to user and to the business, and help the team understand why it's important.

That said, I don't have a designer, so by way of communicating, I'm going to share a few screenshot mockups to illustrate a few possible solutions to the problem.

When possible, you want to think in terms of common design patterns.  Be creative, but not too creative.  A common UI-pattern for changing prices is a slider (think Kayak).


In figure 2, I borrow Kayak's price slider to let the user perform a "What If" analysis on the summary page.

The bordered box and the fonts clarify to the user that the loan term has not changed.  This is simply a what-if calculator for informational purposes.

An alternative to leaving the UI as is, would be to make this kind of calculator a pop up, or placed on the side navigation bar (below the referral incentive, for example).

Figure 2

Payment Spinner

Perhaps another way to solve the problem and keep the UI clean would be to add a spinner to the Next Payment line.  In figure 3, you can see the up and down spinner, and next payment dollars in brown font.

It goes without saying that the amortization calculator in the backend would adjust the due date accordingly.

Figure 3

FAQ Approach

Now, I am not a Lending Club product manager, and therefore do not have a broader view of the problem and its impact.  Let's suppose I have access to customer support calls, and this happens to be a frequently asked question, and something that is not yet automated.

The best first approach to this problem might simply be to provide the user more information (it'd be worth parsing some of those customer service calls) and provide a self-serve page explaining the impact.

All you really would need is a hyperlink that answers "Can I pay more?"

In figure 4, I visualize what this could look like.  I added a red dot with question mark as a way to create a common UI pattern within LendingClub site itself.  Whenever we find a common question, we can insert it within the default screen.  It acts as a supplement to the "Common Questions" already found in the side navigation bar.

Figure 4

Stepping Back and Advocating for the User

It is the product manager's job to advocate for the user, and understand the business goals.  If the user wants to increase the monthly amount (in the slider example), it could be a signal of financial strength.  However, if the user wants to decrease the monthly payment, it could be a signal of some problem.  For the business, this presents an opportunity to deliver user delight, and at the same time mitigate business risk (for example, by providing pertinent information or options that mitigate default risk).

On the whole, I think there are other small improvements that can be made to the summary borrower screen.

For example, as a borrower, I really want to know what the overall amount of money I am paying is going to be, interest and all.  Rather than purely text-based rendering of that information, a progress-bar type of visualization could be much more effective (and would be relatively easy to implement).

And as a borrower, I might be confused to see the lenders of my loan.  Thus far, nothing in this space has shown me I have any incentive or useful interaction with the lenders.  It's a distraction, unless it were clearer to me what I am to do with that information (figure 5).

Figure 5

Testing, Revenues, Summary, etc

Let's suppose that the user actually wants to pay off the loan faster.  The first task is to work with the designers to design some possible solutions (as we did above).  Next,  we would want to consult engineering (or communicate to them) to ensure that the implementation is feasible within time or other resource constraints.  

I can say that all of the changes suggested above are mostly cosmetic, and would not take long to implement.  The thing is, you don't actually know a priori whether it is going to help or harm your business.   


You already know that I'm going to tell you you need to test.  Since the changes are relatively easy, I would opt for having multiple versions of possible solutions and running A, B, C tests in different markets and segments to see which ones perform the best.


Moreover, for those borrowers accelerating payment, you want to convert that intent to a new call to action.  For example, "would you be interested in becoming an investor?"  Why not, you have money spare.

Here, Lending Club has a potential weakness.  Unlike on Prosper.com, on Lending Club, you need to create separate accounts to lend and to borrow.  Why?  Why can't I be both a lender and a borrower from the web product perspective (never mind the regulations for a second)?  The answer is, no reason at all!

As it is, Lending Club will need two separate email addresses from you for you to be both a borrower and an investor.

Figure 6

You might also like ...

If you enjoyed this product teardown, be sure to check out:

Do you have articles or teardowns of your own to share?  Check out productmanagementfasttrack.com.

Prosper 1 Click Quote, Not Really 1 Click

Prosper P2P Lender

According to its website, "Prosper is is America's first peer-to-peer lending marketplace, with more than 2 million members and over $2BB in funded loans."

I've been a Prosper member for years, an early adopter since the first days before other competitors popped up.  I've also been a fan of Kiva.org (a similar, yet different kind of service where the loans are made interest-free to developing world individuals), where I have made over 100 loans.

1 Click Quote

I've only used Prosper as an investor, loaning out small micro-loans to various users - most of them consolidating debt, or paying off an auto loan, or borrowing money for home improvement.  I decided to see what it would look like to become a borrower.

I loved the simplicity of the trigger from the investor summary page, prompting me to consider borrowing a loan.

Figure 1

You are teased with a low APR, and big call to action "Get Rate" button.

Now, I'm already logged in as a user ... meaning my basic info is available.  Too bad, then, when I click on Get Rate, I'm routed to this page.

Figure 2

Prompting me to provide the purpose of loan and some other basic info.  It still like the clean UI, but my problem with this is, why make me repeat the same information?  (Figure 1 and Figure 2 essentially duplicate information).  Why make me do this?  

Further disappointment then, when I am routed to the next page, where I am told "Get a Custom Rate in 1 Click."  This is my 3rd click, so I feel this is bit mismatched from meeting expectations point of view.

Figure 3

Understandably.  Many of this has to do with the regulated nature of lending and borrowing industries.  Often, the business constraints are such, that the end goal is not the most streamlined user experience (UX).  Sometimes, it makes product sense to create some friction for the user.  That said, I think there's clearly a room for improvement in conversion and user experience here.

Anybody home?

As another example of UX issues I found with Prosper.  When I go to my investor profile page, I see something like this.  This is me (figure 4).

Figure 4
 What happens when I click on the "View" hyperlink?  I get a broken link.  Page Not found (Figure 5).  Which is not bad.  The page reroutes to the summary page shortly.
Figure 5
However, look at a different Page Not Found message by another product - StackExchange.  There, you see clearly more humor.  It is a way of empathizing with the user.

"You didn't find what you were looking for?"

"We are sorry, let's see if we can at least make you smile while we help you."  That seems to be StackExchange approach (Figure 6).

Figure 6

You Might Also Like ...

If you enjoyed this product teardown, you may also enjoy:
And a product teardown is intended to help you become a more effective product manager by improving your acumen.  There's a whole lot more to this profession.  Check out this book:

Take Charge Product Management: Take Charge of Your Product Management Development

Keep on building!  Good luck!

Feb 5, 2015

Taking Assembly for a Test Drive

I have been taking the web product Assembly for a test drive.

Assembly is a platform for crowd-sourced web-based products.  A product for product development online.  Sounds like recursion!

It's got to be a dream for programmers and web geeks!

Product Description and Traction

Assembly is really interesting, just because you get to see what other people are thinking about, in a transparent way.  The product seems to have solid traction based on cosmetic review of the activity.  Here are some key observations about this product.

Coderwall Project bounties and contributors (from Assembly)
  • Virtual - The projects are mostly virtual from around the world.  The landing page is filled with many approved and pending projects.  A large product like Coderwall has 100 contributors, although contribution follows a steep power law distribution (probably even more than 80/20 rule - meaning 5% do 95% of the work ... the nice thing is, they are paid accordingly). 
  • Platform - The diversity of products is as wide as people's imagination.  Of course, what Assembly provides are the building blocks (see below) of a web product building.
  • Revenue Positive - As far as I could tell, Coderwall is its most profitable product; based on 2014 payouts, it seems to have about $24K MRR with 86% profit margin.  Wow!
  • Engineer Heavy - I've joined a few products and started one to test the default experience.  I don't have hard figures, but based on new people who sign-up to a project, the site is engineer heavy, followed by designers, followed by non-technical people.

What Are the Building Blocks of a Web Product?

One of the reasons Assembly interested me was that the product makes you think about what the building blocks of a web product development are.

In essence, Team Assembly would have had to deconstruct the core elements of software development, and so doing, virtualized and abstracted a traditional coming together of a team.  Abstraction and virtualization are both long-term trends in the software-centric world.

So, apart from that interesting academic question, here's my hypothesis about what Assembly believes are core building blocks.
  • Software engineers - Which is great, because a platform like this would be self-selecting to software engineers who are used to working "in the web."  Remote working is a norm in this community.
  • Comprehensive communication - Communication is key in product management.  Many good vs. bad outcome can be traced back to good vs. bad communication.  Assembly uses Slack threads for each project you join.  Seems like a good solution.
  • Project management - This seems to be a missing piece of the platform.  Teams likely will use a Trello board or Google docs outside of Assembly.  The communication threads are nice, but not sufficient for serious collaboration. 
  • Version control - Assembly-built products are linked to Github repositories.  There is no separate bug tracking here, but can be managed through communication threads and pull requests.
  • Incentives - I think Assembly's solution is particularly novel and effective.  I think it is very meritocratic, because coins are awarded based on contribution.  The overall model is very Silicon-Valley-esque. The founder holds the lion's share of initial coins, and if everyone maxes out the contribution efforts, the founder's holdings can be diluted down to 50%, and everyone else holding 50% ... unless founder herself is doing a lot of work and awards herself.  Apart from monetary incentive, the product also leverage's people's sense of curiosity and personal value. You can say, "hey, I'm only a designer, but I can add this little piece to the overall effort!"  And so on.  For many, I would say, money is a distant second or third incentive.
  • Team Trust - This is another challenge.  Trust is really hard.  Most startup teams at least, fail because of bad founder selection.  Here, the process is just left up to the wind.
What else is important to building a good product?  Really, it is customers, and a good process to deliver what those customers want.  That's it.  If you don't have customers, things like project management, engineers, and everything else doesn't matter.  Only thing is, some startups start out with a hypothesis they can get customers, and start building.  But, in the end, you need customers.  Communication, version control ... don't get lost in the details.  

It's just tools and processes to serve the customer.

Assembly's mix of light-weight and mostly off the shelf tools is an interesting approach to discovering better ways to build for the customer.

You Might Also Like ...

Are you a product manager?  What's your philosophy and approach to building great products?

You might also like the following teardowns and meta talks on products: