Crafting successful products - Techstars Amsterdam/Stockholm

Floor is yours, Kaushik.

Cool.

Let's kick off then. So, hi everyone. Thanks for making the time and sorry for the slight delay in getting this started. My name is Kaushik and this session is on how do you build successful products as an early stage company? As someone who builds products for a.

Living, I found that there is a.

Lot of jargon in the product space and also a lot of the frameworks and a lot of the articles and a lot of those things are generally.

Not as applicable to early stage.

So I thought when I was talking with the techstars team about this, I thought let me try and make this as like boil it down to the basics. So this is literally like a one on one presentation for someone who's never.

Built a product before.

I understand that all of you are at different levels of that expertise, but hopefully you will find something useful to.

Take away from this session.

This.

I have enough content for about 45 minutes. It doesn't.

I mean I know everyone says that.

I want it to be a dialogue, but I genuinely do mean that I.

Don'T have enough content for an hour and a half. So please ask questions.

With that.

We can. We can start off.

Next slide please. So views are personal, don't represent any organization, etc.

Shout outs on social are welcome, but.

Please don't share just like that anywhere publicly. I. I would very much appreciate that that is okay. So who am I? So I've built several products in my.

Career and I always say that like.

I'm only as good as what I ship.

I am someone who believes that product building is a craft and not like.

A domain specific thing and I've tried.

To prove that time and again in my career.

So I have. So these are some examples of products I've built.

So I built a men's skincare range of products.

I've built a shampoo range of products which are physical products. I've built ads infrastructure for Facebook. I've built a way for app developers to make money. Both of those products together ended up.

Doing about 5 billion in arrival for Facebook.

So pretty large scale infra products for Stripe, which is where I work. I've built products on payouts where users.

Can pay out in 15 currencies.

I've built instant payouts and a SaaS product like invoicing. So generally my career trajectory has been starting off in consumer goods at L', Oreal, spent some time at McKinsey because I like punishing myself and then spend.

Some time at Facebook and then Stripe.

With a short Stop at business school outside of work, on Saturdays and in the evenings. I like helping startups specifically on how.

Can you build a truly product led company.

And out of that thesis, I invest in companies, so I'm an angel investor in about 15, although I advise more than I invest one board seat. And separately I'm like an official advisor to five startups. But I think I must be meeting.

At least about eight or 10 a.

Week just to try and help out because I think, I think Europe could use a lot more of that Silicon Valley mindset.

Last is sparkling water is a very important part of my life.

I'm a sparkling water aficionado.

So if you have any sparkling water recommendations outside of the usuals, please let me know. Yeah, so I hope no questions on that, but we can, we can move on.

So like I, like I mentioned at.

The beginning, I think product building is a craft that I believe is domain agnostic. Obviously there are specificities in each domains and there are exceptions in, in all.

You know, into all rules.

And so for example, like when it comes to building data products or when it comes to building cybersecurity products, domain expertise helps. But I generally think that a PM's job and here I'm using PM as.

A role and not a job or a title.

A PM's job is to solve user problems using technology, thereby creating some kind of a business impact.

And I think that this is very important to kind of reflect on because.

A lot of founders I meet talk about, hey, I had this idea or I want to start a business. And I think all of those things.

Are great, but they don't really build generation defining companies.

A generation defining company usually is built by solving a very, very deep user problem, ideally using technology so that you.

Can have infinite scale.

PMs do this by creating products and.

It'S a little bit like how an.

Orchestra conductor creates a symphony.

Most people say that, hey, what do PMs do? Like, what is their role?

They don't really specialize in anything.

Do you really need a pm?

I think it's very similar.

Those of you who might be inclined.

Towards classical music, it's very similar to how I think an orchestra conductor creates a symphony.

They don't know how to play a violin or a drum or the drums or a guitar, but usually the symphony.

Turns out quite well.

Like I said, there's also a lot of noise.

If you go to Twitter and just.

Type product, I think there's enough there to last a lifetime.

Lots of complicated structures.

I, I generally try to keep Things.

As simple as possible and I've tried.

To do that over here.

So just a disclaimer that this is.

More one on one.

I think a lot of the frameworks.

Et cetera are necessary at scale to be quite honest. But I understand that all of you are at a pre seed seed stage.

And I find that there is a.

Lot of gaps in knowledge at this stage. I genuinely believe that for pre seed seed stage most founders, most don't need.

To think about how do I build.

The best product possible. I think at pre seed seed stage.

All you need to think about is how do I get to product market fit and is what I am building.

Going to make progress towards product market fit? That is really the bar with which you should judge everything.

So maybe you don't need the great.

Docs, maybe you don't, maybe you do.

Maybe you don't need that great feature, maybe you do.

But I think the bar should be really thinking about does this help me.

Get towards product market fit?

If yes, I will build it. If no, I will not build it. And I'll focus now on some of.

The tools to port over to that you can use from big tech to port that, that you can use as.

An early stage company. An ideal outcome at this at the end of the session is you're able.

To be in the top two box.

Of I have more practical knowledge about.

Building products than before. I think I'll be quite disappointed if.

You leave here with the framework. I will be quite happy if you leave here and say hey, I know what I'm going to use tomorrow and.

It'S going to help me in my day to day. So that's what I am going to.

Focus on in this session. Any questions so far?

Okay, let's move on, let's move on.

So I think the first is like a lot of founders I see start hiring PMs right? Like I've seen like seed stage company hiring first PM and I think there's something, I mean, you know, I think.

It works in some places, but I think in a lot of places, especially in like pure tech companies, I think.

There'S something a bit amiss about it. Let's, let's let me try and explain why. What is the job of a pm, right?

The job of a PM output wise.

Is to define context, define end state.

Shape the product, you know, define what.

That looks like, coordinate actions across different teams and ensure success.

And in order to do that a.

PM needs to make lots of decisions, right?

If you look at the inputs bucket.

On this side, most of them are decisions and some inspiration. And all of those can happen if.

You have a certain kind of environment. But if you focus specifically on what.

The job is, the job is actually making decisions.

And if you are building a technology.

Company, and specifically if you're building a.

Product led technology company, then product is the beating heart of what you're going to do.

So if you're hiring a PM as a seed stage founder, in a lot of cases you are actually outsourcing decision making to somebody who is not you.

And if you're a technology company that is product led and you're hiring a.

Pm, then you're basically outsourcing your company. And I'm not sure if that is the best way forward. I firmly believe that if you're building a tech company, founder is the pm.

Founder should remain the PM because founders.

Has to make all the decisions until.

You get to product market fit, whether.

That'S series A, series B, whatever that may be. At best, if you feel like, hey.

Like, you know, I'm a founder, I've got to do fundraising, I have to.

Do this, I can do that, I.

Don'T have the time.

Hire someone for execution, someone who's more junior. But I think the PM job should.

Be the founder's job until you hit.

Product market fit in terms of what you're doing.

I would hope that this is somewhat controversial.

So please ask me questions if you have any.

Just one question.

Yes.

What if there are multiple founders?

One of you plays the PM job.

So ideally you want like one person.

To focus on fundraise, one person to focus on pm. Does that work? Yeah, yeah, that works.

Okay, great. Cool.

Any qu. Any other questions here?

Can we move on to the next slide?

Okay, let's move on to the next slide.

So let's talk a little bit about this, right? I think all of you don't click next. Don't.

Don't click next Agent.

So I like, I just thought we'll do like a little exercise. If you have like a pen and.

Paper, can you please describe what problem.

You'Re solving in one sentence with your company?

And I would, I would want to pick out like one or two people.

From the group, you know, to kind of like demonstrate.

We can wait 10 seconds and then.

We go from there.

Does anyone want to volunteer and tell us a little bit about what, what.

Problem you're trying to solve?

I can go, yeah, sure.

Basically, we are trying to build a software for accountants so that like, they can collect data from their users much faster and the problem there is that users don't want to do it. You know, they don't have this culture.

Of.

Taking care of their accounting early on. They just keep it until the end of the quarter, and then they just dump all the physical receipts, all the physical invoices on their accountants, and then they spend hours and hours just to put all this information manually inside their system.

Got it.

So, very specifically, Dimitri, and this is.

I, I.

This is more of an exercise that I want to do with you. Is can you describe the problem in one sentence? Like, that's. That's all I need.

Admin.

Not the solution, just the problem in one sentence. Yeah.

Admin is complex and takes a lot.

Of time for who?

For accountants.

Collecting data from their clients. Takes a lot of time for accountants.

So collecting data from clients takes a.

Lot of time for accountants. Yeah. Okay, great. Perfect.

Thank you.

Any. Anyone else who wants to volunteer? Yes, please.

So, unconventional borrowers are denied a proper.

Mortgage in the uk.

Unconventional borrowers are denied a proper mortgage in the uk.

Great.

Anyone else? Yeah, Jordan, please, go ahead.

Students from developing countries can't afford a master's program in Europe.

Okay, great.

Let's go for one last one, and then I'll move on to some tests.

That you can do with this problem.

Any. Anyone else? Last person? Yeah, please go ahead. I think someone's raising their hand there.

Startup founders lose a lot of equity when fundraising.

Startup founders lose a lot of equity when fundraising.

Yes, I think that's.

That's a very good. Yes, that is definitely a problem. Great.

So I think those are all, like.

You know, some amazing examples of what.

The problem looks like.

I think what I.

What I specifically wanted to call out was problem.

And one sentence are very, very important, obviously from, like, a fundraising point of.

View, but also from a, you know.

Product shaping point of view. I think that the trap that a lot of product managers, and I'm using product managers as a broad term here to include founders as well. The problem is that a lot of.

Us get caught up too much in the details, where sometimes we lose sight of how simple it can be because we start worrying too much about features or we start worrying too much about the solution.

And I definitely do not mean to.

Pick on Dimitri here, but if you.

Notice Dimitri's first answer versus Dimitri's second.

Answer, both of those were very different.

Right.

Like, the first answer you're required to follow. The first answer had solutions. The first answer had customer Personas, but.

Didn'T, like, elucidate the problem that well.

But the Second answer elucidated the problem really, really well. And I think it's very, very important.

To keep repeating that to yourself while you are building a product because in.

This one hour, 90 minute workshop, it's fine. But you know, you start doing this.

And you're in the weeds and suddenly three months later you've gone down so.

Far down the road that you're no.

Longer solving the original problem that you've done discovery for. So if you can click now for the test. So I have a few like tests.

That I try to do when, when, when we, you know, when we look at any problem. And I would love like a volunteer.

From someone who'd spoken up earlier or you know, someone new and we can go through these tests for your problem.

If you'll be interested.

Anyone wants to volunteer.

I can't really see the full room.

So please just start, start speaking if anyone's interested. Beyond. Yes, I think you raised your hand.

Yes.

Is it a real problem? I think this is more of the summary.

So can you repeat, can you repeat your problem again just so for everyone's benefit?

Students from developing countries can't afford to study in Europe.

Okay, so is it like, unless you.

Do like a back and forth just.

To, just to kind of demonstrate this, is it, is it a real problem?

I mean the question is it a real problem? Is probably the summary of everything underneath.

Right?

So not necessarily. Right.

Like, I mean, in this case, some sub questions I would ask is do.

Students from developing countries want to study in Europe? Like you would want to go down.

To that level to understand if it's.

A real problem or not. I'm not, I'm not questioning your particular company or your particular thesis.

I'm just trying to demonstrate what, what.

One would think I have to think about.

Right. So students from developing countries find it expensive to study in Europe or cannot.

Afford to study in Europe.

Do they want to study in Europe?

Yes. I mean there is a significant proportion of students who already study in Europe. Like there's about 150,000 students in Germany or outside of Europe. And in the rest of Europe there's similarly high numbers and there's even more which would come if they could afford.

It, but they can't afford it, so they don't come.

Right.

So spending more time on the problem.

Space, you're saying that students from developing.

Countries cannot afford to study in Europe, but there are a lot of students from developing countries studying in Europe. Those two statements are not, are not.

Consistent with each other. Right. So how would you Rephrase that problem.

I think I said have a hard time to board. So some of them have rich parents and the rich parents, like yeah, from Kyrgyzstan, you might have a jackpot and you have rich parents and they afford you to study. Yeah, some of them do not.

Okay, so is it, is it fair to then rephrase your problem as saying that students from low income families in.

Developing countries cannot study in Europe?

That's mostly fair.

We've seen a couple of people who.

Could afford it but didn't want to borrow money from relatives because of personal pride. But that's a minority issue. Mostly it's because they don't have the money.

Got it.

So, so I would, so this, this.

Is the kind of rabbit hole I would go down. Like this is the level of detail I think that you will need to go down to when thinking about is it a real problem?

Right.

And like really having the nuance and being able to shape that problem in.

One sentence, like being able to identify.

For example, low income or low income or students from families who do not.

Want to borrow or something like that.

Now can you tell me a little.

Bit about why this problem exists?

And obviously I'm not going into as much detail as I would go through.

Normally if I was building your product.

But so I'm just giving an example.

Here, but can you tell me why.

Does this problem exist?

Sure. I think there's multiple reasons why this exists. There's typically a domestic support scheme by the countries. So in Germany there is buffet and different countries have different support schemes for students, but they are limited to citizens and or residents of the country. And in many cases they're extended to EU citizens and or residents because EU is making it mandatory to treat every EU citizen. Similar people who don't fall into one of these two categories are not covered by the blanket solutions which are suitable for the citizens. And then there's a few scholarships which exist, but they are far and in between. So they don't, they don't cover the entirety of the situation. And for traditional lending solutions, people who we are addressing don't have a credit history and don't, don't look like a typical lending client. So they're unattractive for lenders due to the structure of the data.

Got it.

So we can have follow ups on each of those questions, but for purposes.

Of time, let's just go into the lending bit.

Right.

Why do, why does, why do lenders.

Not lend to students of developing countries?

Number one, and number two is why.

Don'T local lenders in developing countries lend to students of developing countries to study abroad.

I think that's a good one. This is a good question. What are the actual problems here as far as we understand the. And I mean I worked in consumer lending before and looked into our models. They're very much backward looking. We look into what income does a person have and how has their repayment behavior been in the past. And we're trying to understand very much from these factors how like whether to lend or not to lend. And if we have a student who just finished a bachelor's degree in engineering in Bolivia or Kyrgyzstan, they will not show up. They have no income because they just finished a bachelor and going to go for the masters. They will not show up on any credit bureau statistics because they never spend.

A day in Europe.

And getting from the credit bureau of Kyrgyzstan is not feasible. So it's just a mother and headache and store them. The paradigm needs to shift from a backward looking risk controlling scoring to a forward looking future income estimation scoring.

So no, no. So you're going to solution there. So let's, let's, let's cut off, let's cut off there. Right. So, and this is, this is the.

Important bit actually because the more time.

You spend on the problem, the lesser.

Time you will spend to find product market fit. This is like my golden rule of.

Building products is spend as much time.

On problem and you will, you will thank yourself later.

So why doesn't like local credit work for these users?

Because you mentioned European credit doesn't work for these users. Why doesn't local credit work?

Like why can't bank of Bolivia fund the student?

I mean to some degrees it does work. There's some lending which does happen. People are by definition out of the country and the interest rates are also not great. But there is some of it happening.

Got it. So, and how do you know all this information?

Like have you inferred or have you, have you, have you spoken to students? How do you know this?

Yes, so we received a bunch of students, we made them a bunch of offers. Many offers were accepted when we made them and some offers were declined because people had alternative offers of funding which were more advantageous.

So this is. So I'm again like just focusing on the problem because people are saying, you're saying that people bought your solution. Yes, people can buy your solution for different reasons.

Maybe they bought your solution because you were cheaper than bank of Bolivia. Maybe they bought your solution because you were the only one who was lending. Maybe they bought your solution because their Friend recommended them. It could be a whole bunch of.

Reasons, but it still doesn't answer the problem question.

Right.

But like some of them told us, like we had one guy, for example, and he said he has access to a loan, but he likes that our product has some mentoring aspect to it.

And he likes that our product is.

A bit more safe in case something bad happens to him. Because in a loan, you need to.

Pay back no matter what.

If you have a loan, you need to repay principal versus interest. So he mentioned despite having a loan as an alternative option, he is picking our solution.

Got it. So in this specific example, Bjorn and we should move on. But in this specific example, you've mentioned mentorship and risk, like low risk being the factors for this particular user to pick your product or someone else's product. Whereas the problem that we started with was affordability, which are different things.

Fair enough, Fair enough.

Right? So I would think about all of these things.

So this is what I mean by like going deep into the problem space.

Because what will happen is you, a lot of people will buy your solution and you'll be like, yes, amazing.

Like, I have found product market fit.

I'm gonna go raise a series A. Then you will go raise a series A.

And either like, you know, you will, you will raise it or, or you won't.

And even if you raise it, you will find that you will face problem when you're scaling.

And then you might have to make multiple pivots. So it's better to spend as much.

Time on this right now when you.

Are pre revenue so that the VCS are not looking at numbers and saying.

Why isn't this going 100 month or month. Cool.

So yeah, so similarly, I would go.

Through like other questions, right?

Like how many people have this problem, like this person that you spoke to or you know, Bolivia, Kyrgyzstan.

Like, what is the combined population of these countries?

How many of them are students and.

How many of them want to study in Europe? Is the time big enough?

Do these people have similar characteristics? Maybe everybody in Kyrgyzstan who wants to study is rich. Or maybe everyone who wants to study.

In Bolivia is not rich.

Those are all options that are there.

But ideally you want people with similar.

Characteristics in a consumer company or companies.

With similar characteristics in a B2B space to do that.

And the other thing also you want.

To think about is why has no one tried to solve this problem before? Is it a question of you knowing.

Something that someone else doesn't?

Which is always a good reason to start a company.

Because I think all Very big companies are made on unfair advantages or asymmetric.

Information or is it just that like, you know, there are solutions that exist and they've just not done a good job. So these are all things that you.

Want to think about in the problem.

Space before you even start thinking of sales solution.

What does a product look like?

I have this idea, blue should be.

The color of my logo.

All of these things are not important.

You do not need a logo.

So yeah, let's, let's move on now.

To the next slide.

But any questions here on the problem.

Problem space before we move on? Thanks a lot.

Quite insightful.

No problem. Thanks for, thanks for being. My.

Being for volunteering here.

I appreciate.

Right, let's move on to the next one. So how well do you know your users?

Right. So I want, I want like ideally one or two people to raise their.

Hand and tell me something about your users that one would not know.

Normally that's not in the public domain.

So, you know, you want to like.

Either if it's different. If you're running a B2B, if you're.

Starting a B2B company, you want to.

Tell me a fun fact about a.

Business, or if you're running a B2C.

Company, you want to tell me a fun fact about your target users. So ideally one or two people, if.

You can volunteer, I would be.

That would be great.

I can go.

Yeah, go for it.

This way. What we do is we help. I'm the CEO of Steady Bricks and what we do is we help fintech companies reduce their cloud infrastructure cost. And it's a B2B product and we have a customer and we have an end user. Our customer is typically the engineering leaders.

CTOs or VPs or EM.

And end users are typically software engineers or cloud engineers. And how do I know these group? I come from a software engineering background, both as a software engineer as well as the em. So I know them characteristics pretty well.

And.

I mean one good fact I can tell about my end users is they don't have any patience in trialing the product. If they want to try something, it has to happen within say a few minutes. If not, they lose interest. So it's a hard bunch to tackle. And building a product for them is extremely difficult to cater that particular need.

Got it. That's amazing. I mean, I can empathize.

I would never want to build a.

Product for my em. I think it would be quite hard. So yeah, kudos to you.

That's a great fun fact.

Any, any.

Anyone else? Yeah, sure. Someone Raised their hand.

Yes, that's Jonathan from Porthos and Co. So we're targeting mortgage loans beyond bank. The challenge is we can't just walk out and start lending money because we.

Have to get permissions or whatever.

So our users in the end are the end clients who describe something and they fall into about six or seven buckets. So any reference, Barristers to locum doctors to entrepreneurs to wealthy retirees with low incomes, to recently divorced individuals with a large lump sum but no income. There's a seven or eight different Personas. But in order to get business done, we need to either refer to or onboard some of the mortgage brokers.

Initially, yes.

They have a very different set of requirements because essentially all they want to do is just print the maximum number of mortgages and get that commissioning quickly. And frankly, in most cases that means.

They'Re not interested in anything that's weird or unusual.

So there's a sort of tension there between the two. And at the same time, we have to be very careful about not talking about lending because the moment we do, the tax authorities and the regulator and everything else immediately scream and sanction us.

Got it.

That's amazing. And I think someone lives in the.

UK and has tried to get a mortgage.

I don't understand why mortgage Advisors exist.

In 2022, but that's a lot of things, I guess.

So let's move on. Adrian and I can walk you through my tests.

And how well do you know your user?

Right. So I really think that the first test is like, do you have them on WhatsApp?

Right.

So, Jonathan, like, do you have mortgage.

Advisors and like wealthy retirees and you know your target audience, do you have them on WhatsApp?

Because I think a lot of people.

A lot of PM's founders, end up.

Formalizing the user research process too much, where you end up creating so many.

Artifacts that you actually end up losing the meat of what is the problem.

That you want to solve for coming.

Back to the problem space.

So people will come up with like.

Funky notes and you know, use like.

Worry more about the note taking tool.

Than the notes themselves and schedule calls.

Once a month and, you know, realize.

Five minutes before that you don't have questions.

I think that you should actually be.

Friends with your users, at least your first few users, and you should be living and breathing. You should know what is the first window they open on their MacBook. You should know if they have a MacBook or if they have Windows.

You should know that level of detail.

Ideally about your first few users. If You're a founder.

And really what I'm trying to get.

To is you should not build for.

Somebody as a pre seed, seed stage founder. You should be building with somebody and that somebody being your first few users, which is very, very important.

Does that make sense?

Yeah. Yeah. Great.

Let's move on to the next slide. Right, so now let's get to the exciting bit, which is like, how have you reached your solution? So can someone who's maybe not spoken before try and volunteer this time? I would love to understand more about.

Your company and how you reached what.

Problem in one sentence and how you've reached your solution.

I can, I can do that. So the problem we are solving is that trade execution on the blockchain for the digital assets is not institutional ready.

Right.

So could you please. Because I'm not 100 sure if I got the question.

Yeah, so yeah, so I think the problem is that how are you solving that problem?

Problem.

Okay. Yeah.

So we are building a trade execution solution that enables institutions that need to regularly rebalance their digital asset portfolio by mainly solving one problem. So by. That's good.

I don't know how to. Is it.

So like, let me ask you, right?

Are you building an infrastructure product or are you building like an application?

Now we're building an infrastructure. At the end we are, we are doing it by bringing the necessary piece, necessary pieces together. So at the end we are connecting, building a solution that on the one hand gives the right interface for doing it, and secondly, we bring the right participating partners together, which are, on the one hand the market makers and bring them together with the asset managers and so enable this process. Yeah, to enable this process. So because right now the process needs to be done manually. It's a hassle. You need to go on different exchanges, you have hyphens, all those kind of things we are bringing together into one solution.

Right now.

This is not really existing.

Got it.

And are you building like APIs or.

Are you building an interface?

So for sure we have, we need APIs in order that the institutions, I mean, especially market makers, can integrate with us.

Got it. So, and why, why are you building APIs and why you're not building an interface? What information led you to that? Our decision.

Yeah, because they are used to work with APIs.

Okay, great.

So you don't want to change.

But on the other hand, API. So because we have two buttons at the end, we are some kind of a marketplace.

Got it. So I'm not questioning, by the way.

I have no idea about, like, about what it is that you're doing all the space. I'm trying to, I'm trying to give.

You questions that you can ask yourself.

Right.

Like, so you mentioned that you have market makers and you have asset managers. Who are you onboarding first? Why are you onboarding, why onboarding them first? Are you building the interface for them? Is the interface suited to them? How did you reach those, how did you reach that conclusion? Because if you decide to build for the market makers first, you have actively decided not to build for the asset managers first.

So that is a decision that you're.

Making, even though it might not seem like a decision.

So you want to think about those things.

And, and that's basically what I was.

Trying to get at.

If you can click Adrian, we can, I can talk to you about those tests.

So I think you want to think about, does your solution solve the problem?

And how do you know that?

Right, like, so, for example, if, like.

I think Jonathan's left the room, but if you think about like Jonathan's unconventional.

Persona mortgage idea, does this solution solve the problem? Maybe his solution solves only half of.

The problem or maybe only one fourth of the problem.

And how do you know you want to test that? What is your decision making process? How did you reach a certain decision? What were some implicit decisions that you made when you chose to prioritize something else?

And you want to think about all.

Of this at every stage right now because time is very expensive.

Time is Runway.

Right? So you want to think about all of that.

Let me also, like, then maybe maybe.

Go back so I can ask Bjorn.

Because I feel like I know most about his business. But beyond, like, do you do, like, why, how are you going to evaluate.

Usage of your product?

Is it going to be number of loans written?

Yes, it's not loans, but I would say it's volume. It's a creaky key indicator.

Yeah, got it.

So if, if, I don't know, like, if 30 people went to business school.

And took 100,000 and if 300 people.

Went to a master's program in Germany.

And took 10,000.

What would you, what would you consider success?

Like, which of these two would you prefer?

With volume being analytically?

Yeah, I mean the volume in both.

Cases the same, right?

In both cases you've learned 300, 000. In one case you lend to 30, you lend to 30 students. In one case you lend to three students.

What is the problem that you're out to solve?

And what.

So you want 30 students, right?

Yeah, 30 students is, I mean first of all, there's more impact there if.

We have 30 people.

Yeah, education.

And secondly, there's education, which is also nice.

Got it.

So that basically means that you don't.

Care about volume as much as you care about volume of like, number of loans written.

Right?

Sure.

I mean, it shouldn't be a thousand euros each, but I think both of them are important.

But yes, yeah. So I'm saying, like, so these are.

Decisions you need to make early on because if you're building, if you're building something for number of loans written, you ideally want to build something that optimizes.

For higher velocity of your product. You want to build a very strong.

Top of the funnel.

You want to probably invest in marketing, you want to find like lots of people. Whereas if you, if you want, if.

You just want like volume of loans, then probably you want to like find a few people who are going to.

Business school in Europe and that will be a much lower marketing cost for.

You, you know, if you're thinking about as a product manager.

So you want to think about all.

Of those things, which is basically what.

I was trying to demonstrate.

But yeah, so keep questioning yourself at every time saying like, for example, like, will your user pay for it?

How do you know that user will pay for it? How do you much will they pay for it?

And so on, so forth.

Again, sorry to pick on you beyond.

But I feel like I think I.

Understand your business the most.

I keep coming back familiarity, but yeah.

Let'S move on to the next slide, please.

Any questions here?

So it's always nice.

Awesome.

Any questions on the solution?

Okay, great.

So you want to then think about, like, can you break down your solution.

Into like the, the smallest, smallest parts? If you can, click Adrian and maybe I'll ask Jonathan here. Right, so Jonathan, you mentioned you have.

Wealthy retirees with low income.

You might have someone who's divorced, who has a lump sum. What is the smallest divisible part that.

You can break your solution down to?

I presume you have some kind of.

A mortgage solution that you're trying to build.

What is the smallest part?

So our theory at the moment, and we're still testing this, is that we're going to basically break it down to two of the seven Personas, one of which is for barristers and one of which would be for, say, tech entrepreneurs. And build a funnel where we optimize SEO and noise and conferences and user acquisition in those two particular slots. Personas across the. And then bring the user in and buy that content and those events and Then feed them into a particular sequence through the product which is specific to the issues that they may face for their particular Persona. For instance, a barrister really suffers from.

The fact that although they have a.

Relatively high income, it's extremely lumpy and unpredictable and so it's really an affordability calculation, improvement past and everything else. Whereas the tech entrepreneur probably has a relatively low income but has the possibility of a lot of wealth not to.

Have a private share. Yeah.

So if I was to like, you know, just going back and forth with.

You, right, like how would you.

Is tech entrepreneur the smallest divisible part.

That you can build for?

Because anyone from like you know, the Revolut CEO to everybody in this room.

Is a tech entrepreneur, which is I.

Would think a pretty wide range. Yeah.

So current theory is it's a series B or C tech entrepreneur, probably initially based in London, in fact probably based in, you know, EC2. Straight shortage.

Got it.

So series B, series C, EC2.

And.

Okay, I think that's, that's pretty specific.

And that's basically what I was trying.

To get at is you want to.

Get to that level of detail in.

Terms of identifying who your user is.

And you know, what is the, what.

Is like what is your first ATT&CK.

Market and you want to be able to quantify impact for each of these. Right.

Like, and one last point is like, so Jonathan, probably you want to consider.

Is it easier to go find tech.

Entrepreneurs series B, series C in EC2 who are desirous of purchasing a house.

Or is it, or is it cheaper.

To go target barristers who live, who work in the city, you know, who have lumpy income? Like which one of these is more expensive to target and which one of these is more expensive to build for? Yeah.

Let'S move on to the next slide please. Unless there are any questions, please interrupt.

Me if there are any questions.

So you want to think about what.

Will you build first?

If you can, if you can click Adrian, we can.

So there's a lot of like stuff on prioritization. Honestly I have found this to be.

Like the most helpful framework in prioritization.

I used to be a consultant so I feel like I will be expelled if I don't put a two by.

Two in every presentation I make.

But I think this is literally the.

Most helpful framework that I have seen.

There are obviously exceptions to this. If you are finding, if you find a big logo customer in B2B you.

You want to make exceptions.

If you find an in time trend, you want to make an exception if you're a B2C Social founder, if you.

See a macro trend, for example, like.

A macro trend of.

You know, let's say you're like selling herbal supplements and.

You have an e commerce site for that and you know you have all.

Of your roadmap ready and suddenly there.

Is a trend of like I don't know, cannabis gummies.

And that becomes a macro trend because I don't know, Drake ate a cannabis.

Gummy on a stage.

You want to then ditch everything that you have on your plate and you.

Want to make sure that you build for that first.

So those are exceptions to it.

But other than that, I think this.

Framework will hold you in good steady every time you're looking to prioritize something.

Do you want me to explain the framework? I think it's self explanatory, but if.

You want me to, I can walk you through it.

Just raise your hand or shout if you.

If you think I should explain it. Otherwise we will move on to the next slide. Okay, going once, twice, twice next time. Okay.

What will you build next? Having a product roadmap is a very.

Very important thing, especially early stage. I see a lot of founders falling into this trap where they're like, look, I'm early stage.

What is the point of planning? What is the point of like having a roadmap? You don't need to have like a detailed roadmap similar to how a PM.

At Facebook or Stripe or Google would.

Have one, but you do need to have a list of things that you.

Want to build in some kind of.

Stack order and you want to have.

Some kind of impact sizing next to it.

And I think that's very, very important.

Because you will lose track. Otherwise you will end up building like the next adjacent thing and the next adjacent thing and the next adjacent thing.

Go into a rabbit hole and one.

One year later you'll realize that you.

Actually didn't end up building what you.

Set out to do. So if you can click Adrian please.

It's very important to have that roadmap. Prioritization, as I explained, is most important.

But unless you have a never ending list of things to build, you will struggle to maintain velocity and direction both. You should have more, more things on.

Your list than you can build or can afford to build. And you should not have any doubt about what are you going to build next?

After, after, after your current feature.

Any questions?

Great.

So this is my favorite.

Avoid the good enough trap and you.

Can, you can click.

I think there are, there is this good enough Trap.

Right.

For those of you who worked in.

B2B before, if you go and ask a B2B user, do you like this? They will say, yes, I like this.

I think it's great.

Then you will go and build it and spend a lot of time and.

Money and resources doing that. Then you will say, okay, now I have built it, now use it.

They will sign up to it and.

They will never use it. That's because B2B users like to have things and they don't mind things being.

Thrown at them, but they don't necessarily need everything.

So similarly, if you ask like a B2C user, excluding social, a prototype, and say, do you like this? This is like a new map app, or this is like a new way.

To get your groceries delivered at home.

Or whatever, they'll say, yes, I like.

It, but why do I need groceries delivered at home? In 10 minutes I can just go.

To my corner shop and buy groceries.

These suggestions might get those suggestions that.

Come after the but might get you to pmf, but they won't really move.

The needle as much.

Last, if you ask a B2C social.

User or prototype and ask do you like this? They will most likely say no.

Right?

If someone said last year that, you.

Know, you're gonna get a notification once a day and you have to take a picture using a front and back camera and you have two minutes to.

Take it, what do you think of this idea? I think pretty much everyone would say it's a terrible idea.

I don't think they would get into the textile accelerator.

But it works, right?

And it works because, and I don't know if it'll survive or not, but.

It does work and it's very successful right now.

And, and it's important because like B2C.

Is all about changing user behavior. So users in B2C, specifically social, don't know what they want. So in B2C social, I maintain that.

The most important thing is experimentation. That's it. You don't know what users want. It's, it's completely art and it's art and experimentation.

So you want to have multiple short set goal. In all of these cases, if you're.

Going to users doing with things like this, you don't understand the problem well enough.

And I know I've been repeating this like a broken record, but it is very, very, very important.

Understand the problem and you will spend.

Less time in finding pmf.

Sorry, what do you mean? Yeah, so I think I know this, but what do you mean by Social and ex Social.

Oh, yeah. So B2C social is like, you know, social networks, basically. So, you know, if you're building like.

The next video or if you're building.

A B2C social app, consumer social app, the dynamics of that are different than a B2C non social app.

So if you're building a grocery delivery.

Company.

You know, 10 minute grocery delivery, I would look at bullet point two.

If you're building the next video, I would build.

I would look at bullet point three.

And Kaushik, one question here. So when you say, are you talking about the product or problem? As in like, understanding of problem, you should not stop at good enough or.

Yeah, understanding of problem should not stop it good enough.

Okay.

You're not talking about the product.

No, the product should definitely be good enough.

You should not make your product the best. It is the worst idea to make.

Your product the best. I think that's.

Unless you're a PMF at Microsoft, in which case it's more than that.

I mean, I. I mean, I think there are a lot of exceptions to that.

I think people are split on this.

But like, you know, LinkedIn is at PMF.

You've used LinkedIn, I presume. And I think we can, we can probably agree that it's not, It's. It's not the best product.

But yeah, I mean, we can, we can, we can argue about this. And I don't think there's one.

Oh, yeah, okay. Yeah.

Adrian, I think you were saying something. No, it's just gonna go on that ex Social. That meant excluding social.

Excluding.

Yes, yes, yes, yes. But yeah, that was very interesting.

I'll let you go on. Cool.

Let's move on to the next slide.

Unless there are questions.

Right. Okay.

Don't be absolutist when it comes to data. I've seen a lot of people fall into this trap. I used to be in this trap. I actually had this quote that if you can click.

I had this quote on my desk at one point.

And I think, I think that's wrong.

With time, I've realized that that's actually mostly wrong. Building great products is as much art.

As it is science. Precede seed is completely art. Series F IPO is science. So it's like a chart like this. Right?

Like it's like a cross.

So as stage increases, like, it's less.

Art and more science.

So use data, of course, but like.

Follow your gut and follow your product sense as well. Even in B2B, although B2B, most likely.

The user will tell you that, you.

Know, I want to see all of my accounting tools in one place.

Like they will actually tell you that much and you understand the problem a.

Little bit deeper and you probably build.

A solution and it will most likely end up working.

B2C I think is all about experimentation like I said.

So data will tell you, but what.

To build the data will not tell you. Data will tell you what experiment to run.

Cool. Shall we move on to the next slide?

Right.

So PMF is not binary.

It is not like submitting Everest if you get clicked.

Adrian.

So a lot of founders are like hey, I found pmf.

This is great.

Now I can relax. Actually the race starts then because you.

Will savor it for a while. But if you don't say relevant, you will lose it. You have to keep building to make.

Sure that you maintain pmf.

I mean imagine the tragedy if you.

Hit like series B and you lose pmf.

And it was traction has happened with.

A lot of companies and that happens for a whole number of reasons.

Right.

You lose touch with the user.

Macroeconomic environment changes, user changes.

You lose interest or energy.

A lot of times founders run out of energy.

It's not an easy job at all.

All of those things happen.

So it's important to build the next.

Thing while you maintain pmf. Next slide please.

Last, last bit here is like some things you can steal from big tech.

Without having big tech scale. So if you can click.

So I think the first one, I.

Mean, you know, stripe.

So this is probably a cliche but.

It actually works like maintain documents for.

Every decision you make.

Why, how and what you learned is very, very important.

Even if you're a seed stage company.

With like three people, that's fine.

Maintain. Maintain a decision log.

Maintain documents for every decision. It will help you over the long term.

Have notes for every user call.

Like the number of founders I meet who don't have notes for user call.

Then I like I spoke to this.

User and I think they said this and I'm like you spoke to them three days ago.

Why don't you have a written record of this?

Is is, you know, it's important.

I believe in move fast and break things shift when you're embarrassed to do so. Obviously have some exceptions if you're, if.

You'Re building like a loan writing product, don't send something that's going to approve.

Everybody'S loan but make sure that shipwrecked.

And embarrassed to do so.

It doesn't have to be perfect.

Specifically with non American founders.

I have seen this and it hurts them in Fundraising and I can actually do a completely different session on this. Tell the story. Do not read the features list.

You talk to American founder and even if they're trying to build something which.

Is not that big, they will tell.

You that they're changing the world and they will tell you a very good.

Story about how they're changing the world.

And that is the narrative that a.

Lot of investors and a lot of.

People who don't have the time to.

Actually sift through everything, buy into. It's usually a crisp, concise, very nice story.

And it is in no way humble.

I think culturally, I guess, like X us, that humility is there, but it.

Is not a good thing because it's.

Not part of the game, I think.

So tell the story.

Don't read the future of this. If you're building a mortgage platform, don't. And again, I don't mean to pick.

On you, Jonathan, you didn't say this, but like, as an example, don't say, I'm building a mortgage platform for retirees.

Wealthy people, you know, blah, blah, blah, blah, blah.

Say something like, I am trying to.

Include the overlooked top 1% or something.

Like that, which makes it sound sexy.

And tell that story because that's what I think people, investors want to hear.

See your dashboards every morning. See your dashboards after you brush your teeth. It's a good rule. You will know if something's breaking.

You will know something's going well.

Have no agenda chats with your users.

You don't have to always talk to them for feedback.

Celebrate small wins again.

You don't need to pop champagne with your team every day, but celebrate small wins.

Building an inclusive and happy culture can.

Go a long, long way in attracting the best talent.

I know people who've taken pay cuts for culture.

Charge more. Always charge more.

If you are building a B2B company.

And you think, I'm going to charge a thousand dollars per seat, no charge like $3,000 and then let someone negotiate.

That down that down 2000.

Most of most of the time.

I see B2B founders falling into the.

Trap of charging less.

Always charge more. Mostly I will say, and this is.

A controversial take, don't worry about the ux.

If you actually spent a lot of.

Time on the product and you spend. If you spend a lot of time on the problem and you understand the.

Problem and your user said deeply, it.

Doesn'T matter if it's a type form with like an Excel at the back end, it's okay. I mean, you know, companies have Gone.

To like series B with technology like.

That last is where possible sell long term contracts.

If you're building a B2B company or.

A SaaS company again like, you know.

Why do you want your Default to be 1 year contract? Make your default a 5 year contract and then let your user come back.

And say hey, hey, actually this looks great.

I can't sign a one year, I.

Can'T sign a five year contract. Let's do three.

You at least ended up with like two years more of sales. So always like pitch high is basically what I'm trying to say with point.

Number eight and point number 10.

Any questions on these things to copy? Okay, let's move on to the next slide.

Thank you.

I am most active on Twitter.

Which.

Is that is my Twitter handle and.

I have a newsletter which I write.

Very infrequently but I'm hoping to write.

More of and you can subscribe there.

So thank you very, very much.

I mean we, I think we still have time, right?

Yeah, I mean good time. Yeah.

Okay, great. So you know, happy to like do.

Questions or whatever is useful.

We can also have longer discussions on the deck.

Can we, can we all sort of company specific questions. Kashmir, Is that all right?

Yes. I mean I think it up to textiles, I guess.

I mean I'm here to try and help. So yeah, happy to if they're okay with it. Sure.

So talking about the sort of 789 percentage that I was talking about, our plan at the moment to tick off at least some of the empty boxes that you highlighted in terms of product is to make sure that we carry on talking to those different Personas and having recorded, I should reassure you, calls with those people and getting to know them and we're giving them gifts and sending them thank you letters for having the conversations and I haven't done the WhatsApp thing.

We'll do that.

Is there anything else you'd suggest? I mean it's a long process. I mean I imagine this is going to last forever in some ways.

So sometimes it helps and may not be the case in mortgages, but sometimes.

It helps to shadow users.

Like especially one thing that like in.

Consumer ends up working quite well is to just shadow users, like spend the day with them.

Again for mortgages it might not be very relevant, but that's another tactic I can think of.

Maybe for mortgage advisors you want to.

Spend time in their office and spend.

A whole day shadowing them.

That might be interesting. Okay.

I have two questions.

Kaushik.

So one is the best Practices for customer discovery calls. So I come from a tech world and pretty much the bread and butter or the framework everybody uses is the bong test. Like that's how the interviews are structured so that you can extract information as much as possible. Is that a good strategy? I mean, I know it's a good strategy, but is there anything else that we can throw on top of it to make the discovery cost even better to extract more insights from the customer?

Yeah. So I would say don't do 30.

Minute calls, do 45 minutes. 45 minute calls.

Especially like in the Zoom world. I've seen that when you do 30.

Minutes, you know you end up with like 15 minutes of discussion.

You can always end at 30, even.

If you have a 45 minute call.

So one to 45 minutes. And these are all tactics, I'm telling you.

So keeping in mind the theme of the session.

Second is don't ask leading questions ever. Third is don't talk about solutions ever. Four is ask about like, like dig.

Deeper into the problem.

And like, I personally like the five Whys framework a lot.

Like, not framework really, but like ask why five times. Like it. It always works well, especially when you're evaluating problems.

And again, this is a bit more specific to you and you are at Stripe and how often do you get facetimes with the customers and how do you actually do your product discovery at your level in Stripe?

So Stripe is very like user first.

And I have actually my top customers on WhatsApp and I talk to three to four users every week at least. And I think most PMs at Stripe do that from, from what I know.

Okay, it's not possible to be, it's not possible to be successful at Stripe.

Unless you talk to users regularly, let.

Me put it that way.

So it's not even, it's not even like best practice.

It's necessary practice.

That's good to know. I know at least Stripe is one of the popular products among engineers. It's one of the greatest B2D product primarily not because product. Product user experience is great. I think a lot of people, at least I know at least I can speak for myself is the documentation. I think that's where every single competitor. And one more question just popped into my head again. How do you go about thinking about product metrics at different stages? You think about different metrics and tracking, but early stages, what is the fundamental metrics?

Again, it's very.

The answer. I know it's most of the time it depends depending on what you're talking but is there any common metrics that we can start thinking about at an early stage?

I mean, honestly, like, it does depend, right? Like, I think using what I said at the beginning of the session might be useful.

Is every metric. Try and figure out if every metric that you're tracking is helping you move.

Towards product market fit.

If a metric is not helping you what? If a metric is not helping you move towards product market fit, it is not worth tracking.

Yeah, thanks for that.

I think that's a great way to think about it.

Thanks for this question.

No problem. Yeah.

So a question for me, Kaji.

So.

I like when you say that actually in the very early stages, it's more art than science. This is no other way around it.

It's all about guts.

And then you accelerate. You have very little time.

Right.

So, so how do you think about like setting up experiments, following your gut, how long you let them run because you need to give them time. So I don't know whether there's anything general useful to say, but what does it trigger when I say that is because you have so little time and many, many experiments to run, potentially.

Yeah.

Yeah. It's a, it's a hard. It's a hard call.

I don't think, I don't think there's.

An easy answer to it, Mike. My.

I would say it depends on whether.

You have.

Deep domain knowledge or not.

A lot of founders have deep domain.

Knowledge in, in what they're trying to build.

So for example, I think there was.

Someone who was an engineering manager who's building a.

Who's building cloud saving for engineering managers.

So in this case, you know the.

Target audience really well.

So I would say you can afford.

To trust your gut a lot more.

If I was trying to build something.

For example, like there was a blockchain.

Asset manager, market maker company, if I.

Was trying to build something like that, I don't know anything of any of those things.

I would not probably trust my gut that much.

So I think it's a subjective call.

On how much domain expertise you have on how much you trust your gut.

The lesser domain expertise you have, the more time I think you need to.

Spend on experiments and the longer you need to let your experiments run in order to prove or disprove your hypothesis.

Super helpful, thank you.

I think that's also a reason why.

Founders with domain expertise get back more than founders without expertise.

So just another question for me is, did you feel anything really changed over the past few years in the way the kind of products are built and the way you have to do experiments.

Yeah.

Like, I think the role of product.

Itself has changed a lot.

Right. In the last like 10, 15 years.

Like if you and I think a lot of, you know, companies outside of the U.S. it's still old school.

Like, I think there are two schools of product.

Old school product is there is a.

Business team that makes business decisions and then tells the product team, which is.

Usually like the technical team, what to build.

And then the product manager is usually some type of agile person who does agile things and their job is to.

Keep engineers in check.

That is old model. And then there's new model, which is where the product manager is basically setting.

The strategy vision, talks to users and.

It'S kind of doing a GM role along with building the product and trust the engineers to build the right thing.

As long as enough context is shared.

So I think the significant shift has.

Happened over the last decade or so.

And I think that a lot of companies are now shifting to the new model.

I think in the US pretty much.

Every company is in the new model.

I think in Europe and Asia that.

Shift is still in progress. I think.

I think in the first model basically.

The product team becomes the IT team.

Because ultimately you have some business person who's usually a salesperson or someone who's.

Like an MBA type person who's saying.

You know, this is what the customer wants and this is what I think you should build, which are usually incongruent with each other. Thank you.

I have one more and that is. Is there anything very specific that you found? It's very different for fintech. You know, you're not stripe, used to be at Facebook, different rules for products. The moment you talk about money, finance or not.

Yeah, I think the biggest difference is.

That you can't afford to move fast.

And break things in Fintech.

Like if you move fast, you will break things, including your company.

It's just not possible.

You have to be super careful in Fintech. You have to sweat over the smallest detail.

You have to make sure that you know you are building the best thing possible. Your failures are super low because you're managing people's money.

So you cannot afford to take a.

YOLO approach to building products.

If it's ads or if it's consumer social.

I mean, be as YOLO as you want. Thank you. Yeah, no problem. Anyone else?

Anyone else?

All right, I think that was.

I might have before for question. Maybe that's one on one of the last points you said charge more, charge more.

Love that.

How and when do you Think it's the. Like, the time is right to charge more when. When you're saying that. I think the moment you start finding.

Like, feature fit, not product market fit, but if I start finding feature market.

Fit, start making as much money as.

Possible from those features.

You should always be thinking about, is my pricing too low?

Like that is. That should be the question on your mind always.

So you don't believe in freemium kind of things and.

Oh, no, I definitely believe in freemium. Freemium is a GTM strategy. So, like, for example, I think if.

You'Re building a SaaS product, you should.

Give it away for free. Give it away for free, make it sticky, get to 100 users, then introduce paid plans, then that'll make 130. Then, you know, slowly you will grow.

That 30 into 50, then increase the price, it'll drop again to 30, but.

Your ARR will keep growing.

So definitely believe in freemium, but I.

Think it's a GTM strategy more than anything else. All right.

That was super nice, super tight, very clear. I'm incredibly happy that you focus so much on understanding the problem and understanding your users.

And I really like the idea.

Do you have them on WhatsApp?

I'm going to.

I'm going to use that a lot. Do you have your user? I think that's a really good kind of way to think about it.

Yeah.

For 100, sure. My first business that I built, we spent one off years building a business for a group of people, like traders of new passenger cars, that we had no clue who they were, what they did. We just thought it was a problem at the Internet, but at that point.

We still sold that the Internet would.

Solve everything could solve.

And then we.

Everybody said they wanted it, except exactly like you said, every single one.

And then when we.

No single one used it.

That's, of course a big extreme, but I really like how you focus on that and that's something that we should all really take to heart in what we're doing here.

Thank you so much.

It was wonderful to have you. Can you see me?

Yes. Amazing.

Yeah.

All right, guys, thank you so much and have a great rest of your day. We can use you. We can have your presentation. Right? We just don't. We're not going to share it with.

Anyone except for internally.

Yes, we're going to use it. We're going to use it. Well, thank you so much.

Sounds good. Thank you so much for the opportunity and I hope you found it useful. Really appreciate it. Thank you.

Amazing.

Kaushik. Thank you so much.

Thanks.

Bye.

Thanks, Adrian, for connecting us.

Yeah, I have a call with Adrian.