Ok, el objetivo de hoy es primero explicar, porque sobre el manejo del producto, no queremos
hablar de issues operacionales o issues estratégicos como, no sé, no quiero hablar
de la escruja o la metodología agil de este tipo de cosas, vamos a hablar en una perspectiva
estratégica, no es sobre las cosas que el manejo del producto, es sobre lo que debería
esperar de un buen manejo del producto.
Así que esto es basado en un libro, un libro de Ben Horowitz, Ben Horowitz es, no sé,
alguien sabe quién es, ahora es un capitalista de aventura, él se llama con Marc Anderson
ABC, él escribió un libro y en este libro hay un libro sobre el manejo del producto
del producto, que es muy, muy, muy, muy bien, así que la idea es basada en ese libro,
pero lo que diré también es mi perspectiva sobre Kipo, así que al final, estaré contento
de responder algunas preguntas que podrías tener o que te gustaría saber en los términos
de Kipo, just feel free to ask. First, who I am, I'm Roger, I'm the founder and CEO at
Kipo, it's an invoicing and accounting online software, I will tell you a little bit more
kind of things that we are do, but first I would like to ask who is a freelancer here
for example, hi freelancer, who owns a company, cool, not bad, and the next question is who
loves to do accounting and administrative issues, you should do, ah, ok, because you're accountant,
isn't it or not, yeah, usually people don't like to do this kind of stuff, ok, if you're
an accountant, sure, but if you are not, you hate it, so the thing is that our main challenge
was to provide a tool so that everyone could, first, I don't want to say about enjoy, but
at least to be as less painful as possible, everything related to administrative issues,
so the way that we can do it is by automating data entry processes, which is the worst things
that we have to face. The thing is that, and the good thing about our product is that although
you are big or you are small, you must do this kind of stuff, because if you don't do
it, the government will come and punish you, so the good thing about our product is that
we are delivering a tool so that everyone is able to use it, but it's a tool that everyone
must do it, so our main challenge was to solve something that nowadays, especially in Europe,
is not solved, because still in Europe, the main programs, the main software are offline,
people still use paper, and we want to change this, something that in the United States or
in the United Kingdom, it's quite different, there are already online accounting servers
like Xero or QuickBooks, but it's something that in Europe, it doesn't happen, so that
was, and in Spain, for sure, it doesn't exist, so this was our main challenge, so this is
the kind of stuff that we do, and at the end, still in Spain, it's complicated, because
people are not used to using this kind of tools, but it's something that everyone knows
that will change, so, now, talking about product management, in our case, and this is the,
for me, the most important thing, we are a company that we are building a software,
we are building a software that sells these, so what we do is to build a software and
sell it, that's what we do here, all the people that is working in Tukipu, so it's obvious
for me, the highest impact, the product is, for sure, the thing that has a higher impact
in the company, so, you must read it properly, if you have a shitty product, you won't sell
nothing, because at the end, to sell things, in general, it's super complicated, if the
product is shitty, you won't do nothing, and everyone will just leave the company because
they don't believe in your product, they don't believe in what they are selling, so at the
end, it's not just about revenue impact, but also, it's about the morale of the team,
so people will start being disappointing and will leave, so, first thing, which is super
important, is that me as a CEO, but also, people who deal with the product, must be aware
that this is all you've got, it's all you've got, totally, then, what is the product management,
the product manager, at the end, is the CEO of the product, and what does it mean, first,
like the CEO, he has a cross-functional leadership, what does it mean, he's someone that has to
be aware of what's going on in the company, in all departments, because at the end, you
are building a product and you are selling it, and you are doing just that, you are working
for thousands of customers, just providing your product, so, the product manager must
understand all of them and understand their problems as possible, and one thing that is
important is that they have a whole full picture of the vision of the product, so he must understand
what we already did, what the things that, it doesn't work, and the thing that it will
probably work, and work on that, and, of course, tell these kinds of things into the team,
so that everyone can be in the same line, a lot of times, product managers are thought
as a marketing resource, this, I think, is a huge mistake, because at the end, okay,
to sell the product, it's important, but at the end, if you don't have this broad vision,
it's a problem, and what usually happens, is that you usually have a lot of excuses,
like, okay, for example, in Kipu, we are 12 people, we are competing against players
who have thousands of people, they do thousands of revenues, I cannot say, okay, I cannot
face them because I don't have money, I don't have resources, fuck it, I mean, just deal
with it, it's your job to provide value to our customers, given the resources.
Of course, we are not Microsoft, we don't have that chance to do it, to spend a lot
of money on resources, okay, you cannot have excuses, as a product manager, you know what
you've got, and you have to face it. For me, product manager is someone who has the
full picture of the company, why I say this, first, you should have the goals clear, in
the sense of, you should know what is the main goal of, for example, if you are in a
board of direction, you should know what are the main challenges that we want to face,
for example, if our focus is about retention, you should understand that your strategy through
the product is based on retention, if your problem is acquisition, so you will face that
all the strategy is based on acquisition, so you should have these higher goals so that
you can then translate it into your team, doing a specific actions, but this is a totally
must, because if not, you are doing just things, but you don't get the full picture and understanding
which is the main goal. Second, about customer underlying needs, sometimes, what is typical,
you go to the customer support department, and you ask, okay, what's going on here, and
you just take the feedback, and just try to go to the development team and say, okay,
people complains about this, this and this, let's do it, for me this is a mistake, a product
manager should understand, okay, should listen to everyone, but at the end, there's an example,
typical example is that people goes to Henry Ford and says, okay, we want faster horses,
no, that was not the solution, the solution was the car, so this is the kind of things
that you should understand, and usually this kind of thing, the customer won't tell you,
the customer will tell about your problems, about a feature that might work better, etc.,
but the product management should be able to go one step ahead and understanding how I
can solve this problem in a long term and being technologically competitive, not just
doing a feature and that's it, and about features, when we say about competitors benchmark,
it's not about to understand, okay, that competitor of mine have this feature, I don't have it,
I will have it, so that I can be as much competent as him, but this is not the kind
of job that they have to do because this is quite a trivial, the thing is that you have
to understand why a competitor is a real competitor or is not, so what I say is that, in our case
for example, there's a lot of invoicing softwares into the market, but at the end, what it
is interesting to know is not if today's is a competitor, but if tomorrow's it will be,
so I know that I am able to produce a much better innovative product than him because
of and reasons, and it's not about features, it's about why they won't be as competitive
as me or on the other way around, why this player that is smaller than me may be a danger
and understanding why it might be a danger, it's not a matter of features, it's a matter
of giving a full picture of what your competitors are doing and what they did, yes, yes of course.
Ok, for example, the technological stack that a company might have, for example, ok,
Walterskluber, Walterskluber, it's a super big company, it's a leader in accounting
software here in Spain, but the problem is that the technological stack makes that they
cannot go online, it's impossible, they try it, but it's impossible, so, ok, Walterskluber,
it's much better than me, they've got a, ok, their revenue is like 90 million just in Spain,
so no revenue, no profits, so it's, yeah, but they've got this problem, so for me it's
an opportunity, although it's a super big player, for me it's an opportunity because it's not
about the feature, they do accounting, I don't do this kind of accounting, it's alright, but
I know that because of this technological stack, I can compete with him, not today, but I will
be able to do it, this is like a super huge example, but this is the idea, ok, and for
sure he has to have an analytical behave, at the end, why I should do some one thing
or the other, please be analytical, if you're not analytical, it's about subjective things,
I mean, customer support people can be subjective, because they are talking to customers, but
at the end, what it really matters is that the product management brings me data, data,
not just opinions, and this is super important, ok, for me, and especially in Kipu and in
NASA's company, a product management should be an engineer, or at least to have some
notions of development, first, for me it's someone who is more close to a development
team than in a marketing team, why, because at the end, must be able to define proper requirements
and this is not trivial, I mean, be able to write things for a development team that
they understand, it's quite complicated, it's really, and this is one of the most important
things, for me, is to try to define proper requirements, this is super complicated and
super important, because at the end, if you've got, ok, our development team is super small,
we are for people, so it's not, I can talk with them, in fact I do as a product management
in Kipu, so I do this kind of stuff, but the thing is that, this is something that is
not just about being able to make, I don't know, a specific feature good, but especially
to development team should respect product management, and this is not that simple, I
mean, usually developers think as engineers, their mind is totally different, but the thing
is that product manager should talk the same language like the developer, and this is not
to be a developer purely, but he has to have, he has to understand them so that they can
both work together, and it's something that seems like, ok, people should be, I mean,
developers should listen to the product manager, yeah, ok, but they have to, it should be
like a respect relation, and this is not obvious, and this is the kind of stuff, the kind of
information that the product manager delivers to the development team, and the goal, the
main goal at the end is that developers help this product manager so that product manager
should be able to understand, first they, I mean, first they have to, the development
team should be, should talk with them, but on both directions, and this is super important,
and it's not that simple, for me, ideally, I would like to have a product manager that
is a developer, because I would like him to spend time trying to innovate directly,
and once they've got like an idea of a given feature or whatever it is, talk to development
team with a previous work already done, for example, if I want to integrate a service into
Kipu, it would be cool that the product manager is able to take a look at the API, understand
how it works, be, take a look if it's enough robust or not, and once this pre-work is done,
be able to find these requirements and deliver to the developers, yeah, ok, this is more
about, ok, this about goals, mainly, it's important, ok, in general it's important that
people have goals, even if it's someone who is like just started, or even it's like a
C position, but for a product manager sometimes, because it's someone who are in a lot of departments,
deals with product, it's quite complicated sometimes to set up goals, and usually what
happens is the CEO don't set up bigger goals to Kim, and what this, for me, the problem
is that then a product manager will just not focus on what the real important things, so
for example, if the goal, for example, it makes sense for a product manager, for a product
manager, the main goal is ARPU, so average revenue per user, for example, so if you set
that goal, he will know that this is important for the company, and everything he's doing
is for this main goal, to increase the average revenue per user, so first, help the product
manager to make that his goals are clear, and then he has to stick to this goal, and
all the decisions should be consistent with this goal.
This is another point, usually developers tend not to care about sales, it's like ok,
I just don the product, that's your job to sale, or to market this kind of stuff, but
the product manager should understand that there's people that is under a lot of pressure,
because salesman, the sales working force should sell, people in marketing have super
complicated goals that they have to fulfill, and at the end, the product manager should understand
that they are selling the product that he's building, so up to this point, the product
manager should understand that these people are facing very complicated goals, and he
has to be able to think in the short and in the long term, why I'm saying this, sometimes
what happens is that ok, if a product is not well sell, it's because the salesman is
a bad person or whatever it is, and this is the easier reaction sometimes, and it's very
important to understand why they face problems, or what kind of things a product manager is
able to do so that they can help these teams, for example, in our case, we work for freelancers
and companies directly, and for bookkeepers, so I can go to my sales team and understand
what are the main problems they are here, he's facing, and how I can help through product
so that he's able to sell better, and this understanding that ok, I've got short term
things that I should deliver, but also long term, a long term vision that I should deliver
as well, but this information is super important so that you can just craft your product properly
and help your teams, and then the thing is that, and something that usually don't happens
is just to think for example that your customers are silly, this is something that you are
building a product, a super cool product, you're super happy with it, but then if something
is going wrong, people said ok, my customers are silly, yeah your customers might be silly,
but this is not a problem, the thing is that you have to face that if your customer is silly,
just work for your silly customers so that you should be able to understand how a customer
really behaves, not in your idealistic startup idea, I understand software service, but usually
people don't understand this kind of, they are used to work with other kind of products,
so just face it and understand that your product is going to be bought for people who might
not talk the same language as you, and for sure you have to understand the real dynamics
of a product, of your daily work, for example in our case, a product management should understand
how people in accounting or administrative department works, and if you truly understand
their problems, how they work etc., you will be able to do a good product, not just based
on your objective idea, or your ideal idea, but understanding that exactly how they work
and how you can help understanding that they may not be as advanced as you would like to
have, your customers, an example, you can do an interface design super minimalistic,
but then for example they don't understand and they won't find what are the things because
they are not used to this kind of pattern, so you should understand that you should do
this kind of things into your product progressively, just don't create patterns that you understand
but they don't, so this is the kind of stuff that are important, and finally for me the
main key skills, besides what I already said, is that first you should be able to communicate
properly to everyone in the team, and that's what is complicated because you should be able
to talk to developers and make that, if you define some requirements you should be able
to ask to five different developers and expect that these five people say the same answer
to your, or the same things for your requirements, but you should be able to communicate to the
sales team, to the marketing team, etc., why, because at the end you are building a product
and you expect that your team sells these products, so you should be able to communicate
everything you are doing in a clear and proper way.
Second one, one of the most complicated things is to balance this short and long term, because
at the end you should understand that there are methodologies, like screw methodologies
that help deal with this kind of stuff, but you should be able to understand that okay
you have to face that you have limited resources and you want to do thousands of things, so
it's super important that you are able to balance this time and cost, and first be a
accountant for what you are doing, because if you spend like, I don't know, one month
doing something, a feature, then you should analyze the impact on your business, and all
the time, so that you can be better on balancing this short term and long term, because sometimes
you just take decisions because two customers ask for it, you spend like one week doing
this, and then okay what was the real return of that, so just don't panic, I mean customers
always complains about everything, but you should be able to balance this time and cost
and this short and long term, and third, about discipline, because it's a super cross functional
position, you should be able to make that everyone is updated, for example in our case,
in Kipple, although we are just 12 people, it gets complicated that everyone is aware
of what's going on, it's really complicated, although we are just in the same space and
we see all the phases all day long, so you should be able to keep, for example, you know
what the scrum methodologies are, okay, this is a way to work, so that for example it helps
do this kind of stuff, it's based on doing, you just set up for the next 15 or 30 days
what you are going to do in terms of product, and then you make daily meetings, like 5 minutes
meetings about what's going on, just try to tell the marketing team, okay, this feature
will be launching one week, and everyone knows that then we should do this, this, and this,
so because you are just, as I said, you are crafting a product and then selling to it,
everyone should be aware, because at the end, when you launch something, sales people should
be able to talk to all the customers that they might be interested in this feature, marketing
team should just create campaigns, I don't know, Google campaigns or whatever it is,
and then customer support people should be aware of what's new, so that if someone asks
for it, customer support people should be able to explain it, so for me it's important
that everything should be updated on everything, and also when I say requirements, if someone
in development, for example, has a question, he has to have to spend the time talking with
them, because it's super important that for example development team understand what he
asks for.