The document discusses product alignment with business needs through three case studies: 1) Square Capital - which provides merchant cash advances using data insights to determine eligibility and repayment schedules. 2) Paddle8 - an online art auction marketplace with services for buyers, sellers, and benefit auctions requiring cataloging, payments, logistics and more. 3) Gmail - which pioneered large email storage, search capabilities, and a single page web interface through innovations in storage, metadata handling, and log-based operations.

1. Products’ Love Story with Biz
How Products Align with Business Needs | @pascallouisperez

2. Created first company in High School, online content management
(think a super simpler version of Squarespace)
Studied programming language theory, wrote compilers, was part of
ECMA committee when at Google.
Co-founded Wealthfront, now one of the largest robo-adviser in the
world.
Helped scale Square: we grew money moving systems 100x fold,
team 16x fold. Opened the Atlanta and NYC offices.
Adviser to companies in Health Care space, Art world, FinTech,
Blockchain, Wine.
Now responsible for product, design, and engineering at Eave, a new
mortgage lender. We make ethical mortgages easy.
Hi!
A bit about Pascal

3. Count to Three
1. Square Capital
2. Paddle8
3. Gmail

4. Business Innovation
We’ll start by looking at what makes this business
differentiated, and what are key innovations.
Breadth of Product
From there, we can look at the product surface and lifecycle
of the key thing (e.g. “The Life of a Purchase”), the
audiences to consider, platforms, etc.
One Deep Dive
And it’s always fun to geek out, so we’ll do a deep dive into
one part of the product which is interesting.
The Plan
Also in threes.

5. Square Capital
• Merchant Cash Advances, think “Pseudo Loans”
• For Square merchants only
• Pre-Approval, and cash advanced next day
• Repayment schedule dependent on daily sales

6. Square Capital

7. Square Capital

8. • Data! Lots of Data! telling a story about merchants type of
business, seasonality, etc.
• Underwriting Models to separate the wheat from the
chaff, and target merchants who should receive MCAs,
and determine how large of an advance is appropriate
• Messaging to effectively communicate with merchants,
without appearing like a spammer with ‘free money’ claims
• Dedicated landing page for merchants to accept their
tailored offers (if they so choose)
• Money Movement capabilities to advance cash to
merchants, as well handling repayment
• Portfolio Review keeping all outstanding MCAs under
close monitoring, and understand default patterns
Life of an MCA
(Circa 2013)

9. Merchant Cash Advance
• Square is purchasing future receivables from the merchant
at a discount with a repayment based on a percentage of
daily sales
• e.g. For $9,000 (today) purchase $10,000 worth of future
sales, with a 10% repayment rate
• Say the business does $500 of business a day, then $50
goes to Square everyday to repay the advance
• It takes 200 days to repay the $10,000
• So it looks like you got a sort of loan over 7 months
• (And I’ll leave it as an exercise to calculate the IRR and
APR if this were a debt product!)
Details about MCAs
Our Deep Dive

10. Much Simpler Regulatory Requirements than Loans
• Risk profile is completely different
• If the merchant goes bankrupt, Square has no way to
recoup its money
• Square purchased future receivables at a price that was
too high… Tough
• As such, regulatory bodies are less concerned about
practices in the MCA world, and specifically do not require
a banking license
• (Though the legalese and compliance is far from simple.)
Why MCAs?
Our Deep Dive

11. Paddle8
• Art auction house, think “Online Sotheby’s”
• Dual sided marketplace, buyers and consignors
• White glove service
• As well as service model arm for Benefit
Organizations

12. Paddle8

13. Paddle8

14. • Appraisal evaluating inbound opportunities
• Cataloguing provenance, description, images
• Auction Curation to organize lots thematically
• Auction Dynamics with enforced reserves, bid
increments, timing, staggered bidding, etc.
• Payments both online via credit card, and direct with
checks and wires.
• Settlement to consignors, via wires
• Logistics drop ship model between consignor and
collector
• Plus The Usual Suspects marketing, data warehousing,
analytics, risk management, financial bits (ledger,
reconciliation, reversals, …)
Life of a Lot
The “For Profit” Side

15. Life of a Benefit
The “Service Model” Side
• Guests Management including onsite physical signup
• Physical Auction with paddle numbers, live display of
multi-channel auction, in the room bids, etc.
• Payments and Settlement
• Logistics
• Plus Financial Bits

16. Prioritization Framework
Our Deep Dive
With so much product breadth, how do
answer “What’s next?”

17. Prioritization Criteria
• Risk vs Opportunity
• Growth vs Customer Development
• Impact on Buyers
• Casual, or Power Buyers
• Impact of Consignors
• Casual, or Power Consignors
• Type of Sale
• Regions
• Revenue Lift
Prioritization Framework
Our Deep Dive

20. Gmail • Does it really need any details?

21. Gmail
• Hotmail offered 2M of storage
• Gmail launched with 1G
• Stunning web UI
• Single paged web app
• Search, threaded conversation, email folding…
Circa 2004

22. • Send / Receive Gateways not easy to have “Google
scale” Mail Transfer Agents, they were built from scratch
• Storage providing 1G to that many users was a
technological prowess
• Search with guarantee that if it is in your inbox, it is
searchable, and vice versa (atomicity across storage &
indexing platform)
• Threaded Conversations, Email Folding and many more
product innovations which required interesting engineering
• Single Page Web App first use of AJAX to have a single
page web app
• POP3 interface and also play nice with desktop clients
(IMAP was added in 2007)
Life of an Email
Tough to be the Postman

23. Storing Emails
Our Deep Dive

24. Characteristics of Storing Emails
• Lots of large immutable blobs — an email (with its
attachments) never changes
• Random access, with high affinity with recency — a.k.a
you mostly read your latest emails
• Write rate is not directly impacting user experience —
a.k.a. if it takes a while to write a new email under load, it
is less bad than if it takes a while to search for instance
• Redundancy is paramount, can’t loose anything
Storing Emails
Our Deep Dive

25. Storing Emails
Our Deep Dive
1. Start by super large redundant blob storage for immutable
blocks, it’s called Google Filesystem (GFS)

26. Storing Emails
Our Deep Dive
Caribou Caribou Caribou Caribou Caribou Caribou Caribou
1. Start by super large redundant blob storage for immutable
blocks, it’s called Google Filesystem (GFS)
2. Backend to store meta-data style information, threads,
contacts, labels, email headers with pointers to blobs, etc.

27. Storing Emails
Our Deep Dive
Caribou Caribou Caribou Caribou Caribou Caribou Caribou
1. Start by super large redundant blob storage for immutable
blocks, it’s called Google Filesystem (GFS)
2. Backend to store meta-data style information, threads,
contacts, labels, email headers with pointers to blobs, etc.
3. Organize it a standard storage system, with redo logs
semantics. Every action in Gmail is a log “new email”,
“star”, “delete”, “add label”, etc.

28. Storing Emails
Our Deep Dive
Caribou Caribou Caribou Caribou Caribou Caribou Caribou
1. Start by super large redundant blob storage for immutable
blocks, it’s called Google Filesystem (GFS)
2. Backend to store meta-data style information, threads,
contacts, labels, email headers with pointers to blobs, etc.
3. Organize it a standard storage system, with redo logs
semantics. Every action in Gmail is a log “new email”,
“star”, “delete”, “add label”, etc.
4. Makes moving accounts easy, replay the log on another
backend (with a few more details…)

29. In Closing
‣ Product innovation happens at many many levels Not just UX, UI, or fancy algorithms. It’s also
about back office considerations, legal structuring, how a service is rendered, etc.
‣ Product process can be a catalyst to innovation and often requires to look at things from a
different angle
‣ Strong tech “necessary but not sufficient” need to walk back from actual pain points, and then
solve them with technical prowess
‣ Product & Business are totally fusional beware of orgs which believe “the biz tells product
what to do”, or which introduce barriers that are imagined