Announcing Byte: a design subscription assisted by AI
Announcing Byte: a design subscription assisted by AI
Announcing Byte: a design subscription assisted by AI
Announcing Byte: a design subscription assisted by AI
Six principles for a successful startup
It's essential to have a solid foundation to create a successful SaaS startup: discover these six Product Management principles.
It's essential to have a solid foundation to create a successful SaaS startup: discover these six Product Management principles.
Line charts are perfect for time series, as the presence of two axes enables you to show trends;
Pie charts are useful when dealing with a finite set of groups (5-7 is the perfect number), and if you want to compare the size of a section of the pie relative to the various groups;
Data tables are the best tool when you need to sort data and compare rows and columns;
Funnels are best equipped to represent multi-step journeys since the steps don’t need to be a single action - they can represent logical sets;
Sankey diagrams are the chart to use when you want to show flows and journeys from one step to the other (e.g. what people do after visiting the pricing page of your product).
Building digital products is a very complex business. There are many moving parts, even more skills involved, and often the loudest voice is the one who decides, regardless of the quality of their decisions.
We started Donux because we are convinced that we can do better, that we can overcome specific ways of making obsolete products and create ever better products, both for the people who use them and for those who create them.
Here are some of the fundamental principles on which we base our work and which we try to convey to our customers and partners.
Output → Outcome
Focusing on the features instead of the results you want to achieve is a problem of many product startups.
But what is the difference between Output and Outcome? Let's take an example. You are a content company and you notice from analytics that there are many more people accessing your content from mobile devices.
Thinking for Output will lead you to say, "The use of smartphones is on the rise among our users. We need to create a new iPhone app."
While thinking for Outcome: "The use of smartphones is increasing among our users. We need to strengthen our presence in the mobile landscape."
The premises are identical; the intentions are not. In the second case, no pre-packaged solutions are proposed. Your competitors probably have an iPhone app, so your first thought is to follow the crowd and create one.
But not everyone may want to install a new app, so a responsive site or PWA might work better.
The risk of focusing on outputs too early is to exclude a priori solutions that could be successful and end up spending more money than necessary.
So think about the results you want to achieve without being limited by solutions.
Deliverables → Results
A Powerpoint presentation is a means and not an end.
Yet often in our companies, we think in terms of what is produced and not of the results that are achieved. We see this in requests like, "Get me a presentation for Friday afternoon to present to management on what we intend to do in the next six months."
Let me ask you a question: is it better to have a 600-page analysis on how to increase your conversion rate or to have a 2.8% increase in subscriptions to your product?
The second option certainly brings more value, yet the focus is often on the list of deliverables and trims on the results.
In the next project, try to focus from the beginning on the results you want to achieve; I'm sure it will make a difference.
Are you tired of the usual reports and want more results? Book a free call → and find out how to get them.
Hero Designer → Co-design
I will be very direct on this issue: in a startup, a product of a certain complexity cannot be designed by just one person.
The days of an art director or a solitary designer who manages to design a product alone, following only their intuitions, are over (or we could say they never existed).
Why? Because products have become extremely complex, and a designer is unlikely to know the domain enough to handle all the cases.
What is the alternative, then?
Co-design, which translated would be "making team members (tech, business, design, marketing, QA, ...) work together on product design".
Whether they are designers and customers, or colleagues from different departments, collaboration is essential to ensure that the product is immediately examined from various angles, significantly reducing the level of risk.
Where to start? Do they take people, throw themselves into a locked room, and hopefully for the best?
As good as it may seem, it's not the best way 😅
A framework like Design Sprint can be a good starting point because it gives guidelines upon which a custom process can be built.
But doesn't having everyone work on the same activity at the same time lower the throughput of the team? In the beginning, it is normal for productivity to drop: on the other hand, you are trying a new way of working that everyone has to get used to.
Over time, however, you will see that downtime decreases, proactivity increases, and also the quality of work. And this is because all team members feel part of the initiative and feel they can make a difference with their actions. Try it; it's magical.
Do you want to apply co-design in your startup? Book a free call →
Phase two → Next week
The infamous "Phase Two" is the graveyard where good intentions go to die.
The scenario is a typical one: at the beginning of the project, a small circle of people (sometimes one) has an idea for a new product/line/functionality.
From there, they start writing a list of requirements and features. Following their personal idea of value, they divides this list into "Must have," "Nice to have," "Phase Two."
Sound familiar to you?
I know, I was guilty too. But what is the alternative?
The reality is that "We'll do it in Phase Two" is a synonym for "I'm not sure how much value this feature brings to users, but it seems useful. I'm afraid if I make this decision now, then one day I might regret it." Yes, it may seem excessive, but not very far from the truth.
A product emerges from the "No" that we say as a founder or product manager. From all the things we choose NOT to design, NOT to develop, and NOT to release. Those who say the opposite, those who think that it is how many functionalities the product has, are only postponing decisions that will have a great impact on the economic performance of the company in the medium to long term.
So how do you go about canceling "Phase Two"? The solution is simple: clear the backlog of planned activities beyond two months. When the startup is small, having one or two initiatives to work on and focus the whole team on is the best way to increase productivity.
And in any case, after a certain period of time, the activities must be analyzed again because the context in which we work changes rapidly.
For each initiative, you must then have the answer to these questions:
What is the goal?
Where do we stand now with respect to this goal?
What is the biggest problem or obstacle that separates us from achieving that goal?
How do we try to solve this problem?
What do I imagine happening (hypothesis)?
What actually happened, and what have we learned?
(Source: Escaping the Build Trap - Melissa Perri)
Kill everything else. If it's not between the two things that bring more value to your users, then you might as well not occupy mental bandwidth or have it around in Jira / Trello / Asana.
That way, you'll always be ready to work on the most important thing, not in Phase Two, but next week.
Gut decisions → Data-informed
Is it better to be data-driven or guided by instinct?
We greatly overestimate our intuitions and gut decisions.
On the other hand, when designing a product, the only validation possible is when there is data supporting our hypotheses. There isn't much room for features that satisfy our ego.
The reason is simple: the product we are creating must bring value to its users so that it can bring users to us at a later time.
Order is important: first, give value to your users. Only then do you get value for yourself and for your company.
Product Design is a cruel discipline that requires a lot of psychological strength in not sticking to one's ideas and destroying them if they don't succeed.
We are not all ready to do it, but it is the first step towards a successful product.
But I want to tell you a secret: we prefer to be data-informed rather than data-driven.
The difference?
Rather than being driven by data, I prefer my decisions to be influenced by the information I glean from the data.
So, next time you propose an idea to your team, ask yourself: what data do I have to support my decision?
Being data-driven can give you an important advantage over your competitors. Want to know where to start? Book a free call →
Endless meetings → Async collaboration
At some point, when working in a team, you have to synchronize.
The most obvious tool has always been to meet in person. How could it be otherwise?
Can you imagine taking stock of the situation by sending letters and postcards?
But well-done meetings can be counted on the fingers of one hand: most of the time, there is no agenda, the person with the loudest voice (or role) imposes their ideas on the others, they end up without activities to do, and this leads to another meeting "so we can close the matter."
An alternative?
A simple Google Doc in which the sponsor of the meeting writes the objectives, possible obstacles, and some references and invites others to write their reflections.
Comments to discuss more controversial points, up to a shared draft of an idea.
By doing this everyone has:
the opportunity to express themselves,
the time to think about what to write
and, not to be underestimated, no one has to take notes (which is always boring!) 🎉
You can always meet to discuss the results and make the final decision in person, but they will certainly be faster meetings!
Conclusions
Thinking about outcomes, producing results and non-deliverables, collaborating asynchronously, being data-informed, working in short cycles, but above all promoting collaboration between teams and departments: are some of the principles underlying the major successful startups.
If you like this way of working and are looking for a partner for your Product Design and UX / UI activities, book a free call or write at hello@donux.com
Line charts are perfect for time series, as the presence of two axes enables you to show trends;
Pie charts are useful when dealing with a finite set of groups (5-7 is the perfect number), and if you want to compare the size of a section of the pie relative to the various groups;
Data tables are the best tool when you need to sort data and compare rows and columns;
Funnels are best equipped to represent multi-step journeys since the steps don’t need to be a single action - they can represent logical sets;
Sankey diagrams are the chart to use when you want to show flows and journeys from one step to the other (e.g. what people do after visiting the pricing page of your product).
Building digital products is a very complex business. There are many moving parts, even more skills involved, and often the loudest voice is the one who decides, regardless of the quality of their decisions.
We started Donux because we are convinced that we can do better, that we can overcome specific ways of making obsolete products and create ever better products, both for the people who use them and for those who create them.
Here are some of the fundamental principles on which we base our work and which we try to convey to our customers and partners.
Output → Outcome
Focusing on the features instead of the results you want to achieve is a problem of many product startups.
But what is the difference between Output and Outcome? Let's take an example. You are a content company and you notice from analytics that there are many more people accessing your content from mobile devices.
Thinking for Output will lead you to say, "The use of smartphones is on the rise among our users. We need to create a new iPhone app."
While thinking for Outcome: "The use of smartphones is increasing among our users. We need to strengthen our presence in the mobile landscape."
The premises are identical; the intentions are not. In the second case, no pre-packaged solutions are proposed. Your competitors probably have an iPhone app, so your first thought is to follow the crowd and create one.
But not everyone may want to install a new app, so a responsive site or PWA might work better.
The risk of focusing on outputs too early is to exclude a priori solutions that could be successful and end up spending more money than necessary.
So think about the results you want to achieve without being limited by solutions.
Deliverables → Results
A Powerpoint presentation is a means and not an end.
Yet often in our companies, we think in terms of what is produced and not of the results that are achieved. We see this in requests like, "Get me a presentation for Friday afternoon to present to management on what we intend to do in the next six months."
Let me ask you a question: is it better to have a 600-page analysis on how to increase your conversion rate or to have a 2.8% increase in subscriptions to your product?
The second option certainly brings more value, yet the focus is often on the list of deliverables and trims on the results.
In the next project, try to focus from the beginning on the results you want to achieve; I'm sure it will make a difference.
Are you tired of the usual reports and want more results? Book a free call → and find out how to get them.
Hero Designer → Co-design
I will be very direct on this issue: in a startup, a product of a certain complexity cannot be designed by just one person.
The days of an art director or a solitary designer who manages to design a product alone, following only their intuitions, are over (or we could say they never existed).
Why? Because products have become extremely complex, and a designer is unlikely to know the domain enough to handle all the cases.
What is the alternative, then?
Co-design, which translated would be "making team members (tech, business, design, marketing, QA, ...) work together on product design".
Whether they are designers and customers, or colleagues from different departments, collaboration is essential to ensure that the product is immediately examined from various angles, significantly reducing the level of risk.
Where to start? Do they take people, throw themselves into a locked room, and hopefully for the best?
As good as it may seem, it's not the best way 😅
A framework like Design Sprint can be a good starting point because it gives guidelines upon which a custom process can be built.
But doesn't having everyone work on the same activity at the same time lower the throughput of the team? In the beginning, it is normal for productivity to drop: on the other hand, you are trying a new way of working that everyone has to get used to.
Over time, however, you will see that downtime decreases, proactivity increases, and also the quality of work. And this is because all team members feel part of the initiative and feel they can make a difference with their actions. Try it; it's magical.
Do you want to apply co-design in your startup? Book a free call →
Phase two → Next week
The infamous "Phase Two" is the graveyard where good intentions go to die.
The scenario is a typical one: at the beginning of the project, a small circle of people (sometimes one) has an idea for a new product/line/functionality.
From there, they start writing a list of requirements and features. Following their personal idea of value, they divides this list into "Must have," "Nice to have," "Phase Two."
Sound familiar to you?
I know, I was guilty too. But what is the alternative?
The reality is that "We'll do it in Phase Two" is a synonym for "I'm not sure how much value this feature brings to users, but it seems useful. I'm afraid if I make this decision now, then one day I might regret it." Yes, it may seem excessive, but not very far from the truth.
A product emerges from the "No" that we say as a founder or product manager. From all the things we choose NOT to design, NOT to develop, and NOT to release. Those who say the opposite, those who think that it is how many functionalities the product has, are only postponing decisions that will have a great impact on the economic performance of the company in the medium to long term.
So how do you go about canceling "Phase Two"? The solution is simple: clear the backlog of planned activities beyond two months. When the startup is small, having one or two initiatives to work on and focus the whole team on is the best way to increase productivity.
And in any case, after a certain period of time, the activities must be analyzed again because the context in which we work changes rapidly.
For each initiative, you must then have the answer to these questions:
What is the goal?
Where do we stand now with respect to this goal?
What is the biggest problem or obstacle that separates us from achieving that goal?
How do we try to solve this problem?
What do I imagine happening (hypothesis)?
What actually happened, and what have we learned?
(Source: Escaping the Build Trap - Melissa Perri)
Kill everything else. If it's not between the two things that bring more value to your users, then you might as well not occupy mental bandwidth or have it around in Jira / Trello / Asana.
That way, you'll always be ready to work on the most important thing, not in Phase Two, but next week.
Gut decisions → Data-informed
Is it better to be data-driven or guided by instinct?
We greatly overestimate our intuitions and gut decisions.
On the other hand, when designing a product, the only validation possible is when there is data supporting our hypotheses. There isn't much room for features that satisfy our ego.
The reason is simple: the product we are creating must bring value to its users so that it can bring users to us at a later time.
Order is important: first, give value to your users. Only then do you get value for yourself and for your company.
Product Design is a cruel discipline that requires a lot of psychological strength in not sticking to one's ideas and destroying them if they don't succeed.
We are not all ready to do it, but it is the first step towards a successful product.
But I want to tell you a secret: we prefer to be data-informed rather than data-driven.
The difference?
Rather than being driven by data, I prefer my decisions to be influenced by the information I glean from the data.
So, next time you propose an idea to your team, ask yourself: what data do I have to support my decision?
Being data-driven can give you an important advantage over your competitors. Want to know where to start? Book a free call →
Endless meetings → Async collaboration
At some point, when working in a team, you have to synchronize.
The most obvious tool has always been to meet in person. How could it be otherwise?
Can you imagine taking stock of the situation by sending letters and postcards?
But well-done meetings can be counted on the fingers of one hand: most of the time, there is no agenda, the person with the loudest voice (or role) imposes their ideas on the others, they end up without activities to do, and this leads to another meeting "so we can close the matter."
An alternative?
A simple Google Doc in which the sponsor of the meeting writes the objectives, possible obstacles, and some references and invites others to write their reflections.
Comments to discuss more controversial points, up to a shared draft of an idea.
By doing this everyone has:
the opportunity to express themselves,
the time to think about what to write
and, not to be underestimated, no one has to take notes (which is always boring!) 🎉
You can always meet to discuss the results and make the final decision in person, but they will certainly be faster meetings!
Conclusions
Thinking about outcomes, producing results and non-deliverables, collaborating asynchronously, being data-informed, working in short cycles, but above all promoting collaboration between teams and departments: are some of the principles underlying the major successful startups.
If you like this way of working and are looking for a partner for your Product Design and UX / UI activities, book a free call or write at hello@donux.com
Line charts are perfect for time series, as the presence of two axes enables you to show trends;
Pie charts are useful when dealing with a finite set of groups (5-7 is the perfect number), and if you want to compare the size of a section of the pie relative to the various groups;
Data tables are the best tool when you need to sort data and compare rows and columns;
Funnels are best equipped to represent multi-step journeys since the steps don’t need to be a single action - they can represent logical sets;
Sankey diagrams are the chart to use when you want to show flows and journeys from one step to the other (e.g. what people do after visiting the pricing page of your product).
Building digital products is a very complex business. There are many moving parts, even more skills involved, and often the loudest voice is the one who decides, regardless of the quality of their decisions.
We started Donux because we are convinced that we can do better, that we can overcome specific ways of making obsolete products and create ever better products, both for the people who use them and for those who create them.
Here are some of the fundamental principles on which we base our work and which we try to convey to our customers and partners.
Output → Outcome
Focusing on the features instead of the results you want to achieve is a problem of many product startups.
But what is the difference between Output and Outcome? Let's take an example. You are a content company and you notice from analytics that there are many more people accessing your content from mobile devices.
Thinking for Output will lead you to say, "The use of smartphones is on the rise among our users. We need to create a new iPhone app."
While thinking for Outcome: "The use of smartphones is increasing among our users. We need to strengthen our presence in the mobile landscape."
The premises are identical; the intentions are not. In the second case, no pre-packaged solutions are proposed. Your competitors probably have an iPhone app, so your first thought is to follow the crowd and create one.
But not everyone may want to install a new app, so a responsive site or PWA might work better.
The risk of focusing on outputs too early is to exclude a priori solutions that could be successful and end up spending more money than necessary.
So think about the results you want to achieve without being limited by solutions.
Deliverables → Results
A Powerpoint presentation is a means and not an end.
Yet often in our companies, we think in terms of what is produced and not of the results that are achieved. We see this in requests like, "Get me a presentation for Friday afternoon to present to management on what we intend to do in the next six months."
Let me ask you a question: is it better to have a 600-page analysis on how to increase your conversion rate or to have a 2.8% increase in subscriptions to your product?
The second option certainly brings more value, yet the focus is often on the list of deliverables and trims on the results.
In the next project, try to focus from the beginning on the results you want to achieve; I'm sure it will make a difference.
Are you tired of the usual reports and want more results? Book a free call → and find out how to get them.
Hero Designer → Co-design
I will be very direct on this issue: in a startup, a product of a certain complexity cannot be designed by just one person.
The days of an art director or a solitary designer who manages to design a product alone, following only their intuitions, are over (or we could say they never existed).
Why? Because products have become extremely complex, and a designer is unlikely to know the domain enough to handle all the cases.
What is the alternative, then?
Co-design, which translated would be "making team members (tech, business, design, marketing, QA, ...) work together on product design".
Whether they are designers and customers, or colleagues from different departments, collaboration is essential to ensure that the product is immediately examined from various angles, significantly reducing the level of risk.
Where to start? Do they take people, throw themselves into a locked room, and hopefully for the best?
As good as it may seem, it's not the best way 😅
A framework like Design Sprint can be a good starting point because it gives guidelines upon which a custom process can be built.
But doesn't having everyone work on the same activity at the same time lower the throughput of the team? In the beginning, it is normal for productivity to drop: on the other hand, you are trying a new way of working that everyone has to get used to.
Over time, however, you will see that downtime decreases, proactivity increases, and also the quality of work. And this is because all team members feel part of the initiative and feel they can make a difference with their actions. Try it; it's magical.
Do you want to apply co-design in your startup? Book a free call →
Phase two → Next week
The infamous "Phase Two" is the graveyard where good intentions go to die.
The scenario is a typical one: at the beginning of the project, a small circle of people (sometimes one) has an idea for a new product/line/functionality.
From there, they start writing a list of requirements and features. Following their personal idea of value, they divides this list into "Must have," "Nice to have," "Phase Two."
Sound familiar to you?
I know, I was guilty too. But what is the alternative?
The reality is that "We'll do it in Phase Two" is a synonym for "I'm not sure how much value this feature brings to users, but it seems useful. I'm afraid if I make this decision now, then one day I might regret it." Yes, it may seem excessive, but not very far from the truth.
A product emerges from the "No" that we say as a founder or product manager. From all the things we choose NOT to design, NOT to develop, and NOT to release. Those who say the opposite, those who think that it is how many functionalities the product has, are only postponing decisions that will have a great impact on the economic performance of the company in the medium to long term.
So how do you go about canceling "Phase Two"? The solution is simple: clear the backlog of planned activities beyond two months. When the startup is small, having one or two initiatives to work on and focus the whole team on is the best way to increase productivity.
And in any case, after a certain period of time, the activities must be analyzed again because the context in which we work changes rapidly.
For each initiative, you must then have the answer to these questions:
What is the goal?
Where do we stand now with respect to this goal?
What is the biggest problem or obstacle that separates us from achieving that goal?
How do we try to solve this problem?
What do I imagine happening (hypothesis)?
What actually happened, and what have we learned?
(Source: Escaping the Build Trap - Melissa Perri)
Kill everything else. If it's not between the two things that bring more value to your users, then you might as well not occupy mental bandwidth or have it around in Jira / Trello / Asana.
That way, you'll always be ready to work on the most important thing, not in Phase Two, but next week.
Gut decisions → Data-informed
Is it better to be data-driven or guided by instinct?
We greatly overestimate our intuitions and gut decisions.
On the other hand, when designing a product, the only validation possible is when there is data supporting our hypotheses. There isn't much room for features that satisfy our ego.
The reason is simple: the product we are creating must bring value to its users so that it can bring users to us at a later time.
Order is important: first, give value to your users. Only then do you get value for yourself and for your company.
Product Design is a cruel discipline that requires a lot of psychological strength in not sticking to one's ideas and destroying them if they don't succeed.
We are not all ready to do it, but it is the first step towards a successful product.
But I want to tell you a secret: we prefer to be data-informed rather than data-driven.
The difference?
Rather than being driven by data, I prefer my decisions to be influenced by the information I glean from the data.
So, next time you propose an idea to your team, ask yourself: what data do I have to support my decision?
Being data-driven can give you an important advantage over your competitors. Want to know where to start? Book a free call →
Endless meetings → Async collaboration
At some point, when working in a team, you have to synchronize.
The most obvious tool has always been to meet in person. How could it be otherwise?
Can you imagine taking stock of the situation by sending letters and postcards?
But well-done meetings can be counted on the fingers of one hand: most of the time, there is no agenda, the person with the loudest voice (or role) imposes their ideas on the others, they end up without activities to do, and this leads to another meeting "so we can close the matter."
An alternative?
A simple Google Doc in which the sponsor of the meeting writes the objectives, possible obstacles, and some references and invites others to write their reflections.
Comments to discuss more controversial points, up to a shared draft of an idea.
By doing this everyone has:
the opportunity to express themselves,
the time to think about what to write
and, not to be underestimated, no one has to take notes (which is always boring!) 🎉
You can always meet to discuss the results and make the final decision in person, but they will certainly be faster meetings!
Conclusions
Thinking about outcomes, producing results and non-deliverables, collaborating asynchronously, being data-informed, working in short cycles, but above all promoting collaboration between teams and departments: are some of the principles underlying the major successful startups.
If you like this way of working and are looking for a partner for your Product Design and UX / UI activities, book a free call or write at hello@donux.com
Line charts are perfect for time series, as the presence of two axes enables you to show trends;
Pie charts are useful when dealing with a finite set of groups (5-7 is the perfect number), and if you want to compare the size of a section of the pie relative to the various groups;
Data tables are the best tool when you need to sort data and compare rows and columns;
Funnels are best equipped to represent multi-step journeys since the steps don’t need to be a single action - they can represent logical sets;
Sankey diagrams are the chart to use when you want to show flows and journeys from one step to the other (e.g. what people do after visiting the pricing page of your product).
Building digital products is a very complex business. There are many moving parts, even more skills involved, and often the loudest voice is the one who decides, regardless of the quality of their decisions.
We started Donux because we are convinced that we can do better, that we can overcome specific ways of making obsolete products and create ever better products, both for the people who use them and for those who create them.
Here are some of the fundamental principles on which we base our work and which we try to convey to our customers and partners.
Output → Outcome
Focusing on the features instead of the results you want to achieve is a problem of many product startups.
But what is the difference between Output and Outcome? Let's take an example. You are a content company and you notice from analytics that there are many more people accessing your content from mobile devices.
Thinking for Output will lead you to say, "The use of smartphones is on the rise among our users. We need to create a new iPhone app."
While thinking for Outcome: "The use of smartphones is increasing among our users. We need to strengthen our presence in the mobile landscape."
The premises are identical; the intentions are not. In the second case, no pre-packaged solutions are proposed. Your competitors probably have an iPhone app, so your first thought is to follow the crowd and create one.
But not everyone may want to install a new app, so a responsive site or PWA might work better.
The risk of focusing on outputs too early is to exclude a priori solutions that could be successful and end up spending more money than necessary.
So think about the results you want to achieve without being limited by solutions.
Deliverables → Results
A Powerpoint presentation is a means and not an end.
Yet often in our companies, we think in terms of what is produced and not of the results that are achieved. We see this in requests like, "Get me a presentation for Friday afternoon to present to management on what we intend to do in the next six months."
Let me ask you a question: is it better to have a 600-page analysis on how to increase your conversion rate or to have a 2.8% increase in subscriptions to your product?
The second option certainly brings more value, yet the focus is often on the list of deliverables and trims on the results.
In the next project, try to focus from the beginning on the results you want to achieve; I'm sure it will make a difference.
Are you tired of the usual reports and want more results? Book a free call → and find out how to get them.
Hero Designer → Co-design
I will be very direct on this issue: in a startup, a product of a certain complexity cannot be designed by just one person.
The days of an art director or a solitary designer who manages to design a product alone, following only their intuitions, are over (or we could say they never existed).
Why? Because products have become extremely complex, and a designer is unlikely to know the domain enough to handle all the cases.
What is the alternative, then?
Co-design, which translated would be "making team members (tech, business, design, marketing, QA, ...) work together on product design".
Whether they are designers and customers, or colleagues from different departments, collaboration is essential to ensure that the product is immediately examined from various angles, significantly reducing the level of risk.
Where to start? Do they take people, throw themselves into a locked room, and hopefully for the best?
As good as it may seem, it's not the best way 😅
A framework like Design Sprint can be a good starting point because it gives guidelines upon which a custom process can be built.
But doesn't having everyone work on the same activity at the same time lower the throughput of the team? In the beginning, it is normal for productivity to drop: on the other hand, you are trying a new way of working that everyone has to get used to.
Over time, however, you will see that downtime decreases, proactivity increases, and also the quality of work. And this is because all team members feel part of the initiative and feel they can make a difference with their actions. Try it; it's magical.
Do you want to apply co-design in your startup? Book a free call →
Phase two → Next week
The infamous "Phase Two" is the graveyard where good intentions go to die.
The scenario is a typical one: at the beginning of the project, a small circle of people (sometimes one) has an idea for a new product/line/functionality.
From there, they start writing a list of requirements and features. Following their personal idea of value, they divides this list into "Must have," "Nice to have," "Phase Two."
Sound familiar to you?
I know, I was guilty too. But what is the alternative?
The reality is that "We'll do it in Phase Two" is a synonym for "I'm not sure how much value this feature brings to users, but it seems useful. I'm afraid if I make this decision now, then one day I might regret it." Yes, it may seem excessive, but not very far from the truth.
A product emerges from the "No" that we say as a founder or product manager. From all the things we choose NOT to design, NOT to develop, and NOT to release. Those who say the opposite, those who think that it is how many functionalities the product has, are only postponing decisions that will have a great impact on the economic performance of the company in the medium to long term.
So how do you go about canceling "Phase Two"? The solution is simple: clear the backlog of planned activities beyond two months. When the startup is small, having one or two initiatives to work on and focus the whole team on is the best way to increase productivity.
And in any case, after a certain period of time, the activities must be analyzed again because the context in which we work changes rapidly.
For each initiative, you must then have the answer to these questions:
What is the goal?
Where do we stand now with respect to this goal?
What is the biggest problem or obstacle that separates us from achieving that goal?
How do we try to solve this problem?
What do I imagine happening (hypothesis)?
What actually happened, and what have we learned?
(Source: Escaping the Build Trap - Melissa Perri)
Kill everything else. If it's not between the two things that bring more value to your users, then you might as well not occupy mental bandwidth or have it around in Jira / Trello / Asana.
That way, you'll always be ready to work on the most important thing, not in Phase Two, but next week.
Gut decisions → Data-informed
Is it better to be data-driven or guided by instinct?
We greatly overestimate our intuitions and gut decisions.
On the other hand, when designing a product, the only validation possible is when there is data supporting our hypotheses. There isn't much room for features that satisfy our ego.
The reason is simple: the product we are creating must bring value to its users so that it can bring users to us at a later time.
Order is important: first, give value to your users. Only then do you get value for yourself and for your company.
Product Design is a cruel discipline that requires a lot of psychological strength in not sticking to one's ideas and destroying them if they don't succeed.
We are not all ready to do it, but it is the first step towards a successful product.
But I want to tell you a secret: we prefer to be data-informed rather than data-driven.
The difference?
Rather than being driven by data, I prefer my decisions to be influenced by the information I glean from the data.
So, next time you propose an idea to your team, ask yourself: what data do I have to support my decision?
Being data-driven can give you an important advantage over your competitors. Want to know where to start? Book a free call →
Endless meetings → Async collaboration
At some point, when working in a team, you have to synchronize.
The most obvious tool has always been to meet in person. How could it be otherwise?
Can you imagine taking stock of the situation by sending letters and postcards?
But well-done meetings can be counted on the fingers of one hand: most of the time, there is no agenda, the person with the loudest voice (or role) imposes their ideas on the others, they end up without activities to do, and this leads to another meeting "so we can close the matter."
An alternative?
A simple Google Doc in which the sponsor of the meeting writes the objectives, possible obstacles, and some references and invites others to write their reflections.
Comments to discuss more controversial points, up to a shared draft of an idea.
By doing this everyone has:
the opportunity to express themselves,
the time to think about what to write
and, not to be underestimated, no one has to take notes (which is always boring!) 🎉
You can always meet to discuss the results and make the final decision in person, but they will certainly be faster meetings!
Conclusions
Thinking about outcomes, producing results and non-deliverables, collaborating asynchronously, being data-informed, working in short cycles, but above all promoting collaboration between teams and departments: are some of the principles underlying the major successful startups.
If you like this way of working and are looking for a partner for your Product Design and UX / UI activities, book a free call or write at hello@donux.com
Subscribe to our product design newsletter
We'll be sending two emails every month with product and design tips for B2B SaaS
By submitting this form, I accept the Privacy Policy
By submitting this form, I accept the Privacy Policy
Donux srl © 2024 Via Carlo Farini 5, 20154 Milano P.IVA IT11315200961
Donux srl © 2024 Via Carlo Farini 5, 20154 Milano P.IVA IT11315200961
Donux srl © 2024 Via Carlo Farini 5, 20154 Milano P.IVA IT11315200961