You probably are going to work from home. You have a great idea for a feature in
your favorite product like Nozbe and you love to see it in the app as soon as
possible because you truly believe it would make things better quickly.
Today we'll show you What's the real journey, what it looks like, from a user
request to a finished feature, and why it's almost never as easy as you might
think, and it's not usually just two lines of code or something like that. So let's
talk about this. How this sausage is made, how we create new features,
how we introduce new features, and what's the customer feedback and how we treat it,
how we love it, and why it always takes a bit longer to introduce a feature to
our customers than you might think. Join with me today, as always, in the episode
91 of No Office podcast is Magda. Hi, Magda. Hello, everyone.
Not always. Recently, I haven't been on the show. Aw. But that was my fault.
Anyway, that's right. Today's episode is totally dedicated to our users,
or maybe to users of other applications, who are wondering why the owners of the
product or the developers are not taking into consideration the great ideas.
So we do. We really note down everything. And we really would like to introduce all
the features that you want or that you need. But the whole episode will be about
this bat. But first of all, we wanted to swear to you that we note down
everything, that we have a special place in Nozbe. We will talk about this later
where we note every feature request, every question,
every suggestion, and we group it beautifully, and we always sign it with your email
address to inform you later if we decide to implement your idea.
But it's not so easy. We promise and we will explain you that even your idea is
great, It's not always possible to click and to just add it to the application.
Yes. So first of all, it starts with the basics.
So it starts with the values of our company,
not of our applications, which is PSFF, which means passion,
simplicity, fairness and freedom. And the thing is that the simplicity part,
especially relates to the product, we want to make sure that Nozbe is as simple as
possible for you to use. So that's the, and also even if it has super powerful
features, which it does, we put them in such a place that they're not overwhelming
the new users. So the idea is that when they jump on to Nozbe and start using
Nozbe, they can start getting things done right away because our target audience are
busy people and busy teams, so they are already overwhelmed. So we want to make
sure that they can quickly start using the tool. But also, there are things that we
have decided how our application should be, and they also constrain us as to what
we can implement. So first of all, the first thing is that our application is
available on all the platforms. So both on the desktop as a web app and as a Mac
app or Windows app, but also on the iPhone and Android. And we want to be able to
give you the same features on all the platforms. So a feature that we implement on
the phone has to be also available on the desktop and the other way around. If
there is a feature on a desktop, it should be available on the phone. Many other
applications that are competing with us,
very often they have very powerful desktop applications and they had all the features
there and then they have very simple, mobile companions. This is not our strategy.
Our strategy is that, And we have many customers who are solely managing everything
from the mobile phone. So we want to enable that. And another constraint that we've
built is that we want our application to work offline.
So even if you have a very, you know, not so good internet connection or at all,
you can still use our NOSPI and, you know, get things done. Very often I've been
doing my weekly reviews on the plane without any internet connection. And I knew,
and I had the confidence that if I, you know, move things around, move tasks to
different projects, complete some projects, complete some tasks, add comments that when
I land and I connect to the internet, everything will sink beautifully.
And this is what happens. So these are some constraints that we put ourselves and
they already dictate a little bit how things are implemented. Yeah, that's right.
We'll talk about it a little bit more. But I just wanted to tell you why we are
recording this episode. Because first, we keep getting ideas from people and we keep
getting those features requests. And we are totally grateful because it means that we
are, I don't know, that our app is important to you and that you want to take
part in improving it. So we take it seriously and we are really grateful. And we
love it. And we note it down and we really registered everything. But you will see
what the process looks like. Then sometimes we also have a task in Nozbe where
support officers, our colleagues from customer support,
note down your complaints and the way you are frustrated or disappointed. And most
of those complaints stem from the fact that you think that we don't take your
suggestions seriously, that we don't introduce your ideas and that, okay,
now I'm going to resign from using Nozbe because you haven't used my suggestions.
You haven't listened to me. That's not how it works. We listen to you, but we just
can't to everyone's request. And we just want to be transparent.
So we want to present how the process looks like. It might be interesting just for
the users, but also maybe for other people who work on SaaS products like ours or
maybe other applications, maybe it will be some kind of inspiration for you. Okay,
so yeah, shall we start or do you have something to add? No, no, we'll talk more
as we explain all the details. But this is, you know, something to be repeated.
Yes, thanks to you, thanks to our users, our application gets better. We've had many
suggestions and many feature requests that we haven't completely, I mean,
of the application, and again, as what Magda said, this episode is to be transparent
about it, how this process actually works. So step number one is we receive a
submission, a feature request from a user. Usually it's a user. Sometimes it's one
of our experts. Sometimes it's one, someone from our team. But usually,
as now our product is pretty complete because we've been on the market for so many
years. So the original project is done. So now we are just probably using the
suggestions and submissions as our main source of improving the product.
And we noted down in a special project called feature requests and we have an
actually special project for it. It's divided into sections. Those sections are the
aspects of the applications. Every feature request or like the,
I don't know how to say it, but okay, let's stick to it. Every feature request has
its own task where we note what people need about did.
And every submission is a new comment. And what the support employees do,
they know down, usually they quote what the user wrote or said.
And also they add their email address only to inform them later on if their
submission was implemented and if their idea was used we have a blog post about it
and you'll find a link to it in our in the in the episode notes because that's a
great way to improve the way the support department work so we have the whole
database the whole list it's really really huge. The project has so many tasks and
so many comments and they are waiting there for their turn.
As you can imagine and we have thousands and thousands of the users, many people
have similar ideas. That's why some of the tasks have maybe two or three comments
if the suggestion is pretty geek or very complicated. And Also, we have tasks with,
I don't know, like dozens of comments, which means that this is a very popular and
very demanded feature. And probably it will be one of the first ones that will take
into consideration when going to step two, which is evaluating the need.
And now Michael will take over because there is the special quote he likes about
not looking for solutions, but... Yeah, so that's the thing.
So what we are looking for are problems. So there is a quote by some CEO or
general saying that, don't bring me problems, bring me solutions. And I think it's
wrong. I think it should be the other way around because there are many solutions
to many problems, but I think the best way to understand,
I mean, to make sure the solution makes sense is to actually understand the problem.
And that's why we try to gather all these suggestions that you send us around these
problems. So what kind of problems people have? Like in the case, for example,
of AI. We just had a webinar about AI, and we introduced our first AI features,
which are shipping as we speak, like this week. So the idea is this.
We had the AI task, and there were people just submitting their issues. There are
things like, oh, I want to use, you know, chat GPT and then paste it to Nozbe, or
I want to do this and that, and then from there, we found our first ideas for AI
features. Thanks to you. Thanks for you. Thanks to you sending us all these things.
Thanks to you sometimes telling us, well, you're so behind. You don't have AI and
Nozbe. Yeah, the competition are already using that. So it was great. Like,
you know, we don't mind the backlash. We digest it. We go through with it.
And then we decide what to do with it. So we want you to bring us problems. And
of course, we listen to your solutions as well, and we take it under consideration.
But because we have thousands of paying users, because Nozbe has this business model.
Like, we, NOSPI is not made for big corporations. So we don't like like three, four
strategic clients and that's it. No, no, we have thousands of strategic clients.
So because of that, who pays us, you know, nine bucks per month. So because of
that, we focus on these thousand strategy clients. We think, okay, you have that
problem. Somebody else has a similar problem. And somebody else has actually the same
problem, but they want to have a different solution. So we analyze all that. So
based on that, we can start thinking about the solution. When we have enough
problems, and then we see some solutions, and we see if it fits what we want to
build. Yes, also don't be astonished when you suggest your feature idea,
and someone from our customer support will ask them, okay, but why do,
why you exactly need this feature, what you want to achieve? And And you say, okay,
because I would like to be able to do this and this and this in Nozbe. And it
might be that there is another way to achieve this. And maybe our colleague from
support, maybe it's easy for her. You just need to use the tag and then filter
something or you might need the integration with the email. Maybe it can be done.
So don't be astonish that we don't always say, okay, thank you, we will note it
down and we'll pass it to our developers. But sometimes we'll just dig it and dig
deeper to see that maybe there is something you don't know about Nozbe, even though
it's pretty simple and maybe there is another solution. I have a story for you,
Magda.
Recently, there was one of the customers sent an email saying that they want a
scheduling feature. And I'm like, what kind of scheduling feature? Like, what do they
mean by scheduling feature? So sometimes you customers are sending us emails with
names that, you know, for you, it's obvious what you mean. For us, like, we're not
sure what you mean, you know, because many things can mean different things to
different people. So I remember they said, you know, we want the scheduling feature.
And I was like, what do you mean scheduling feature? And then I remember first we
wanted to neglect it, but then we were like, but I was curious. I was like, what
does he mean? So we read his email like, and I think like four times. Just to
make sure that we get what he wanted. And then we realized what they want is that
when you have a project and you have tasks, right now, you have them organized,
you know, the way you want them organized, you know, in sections and in tasks, you
know, you can drag and drop order them the way you want. But he wanted a way to
see these tasks, but organized by date in the same project view.
Okay? And then I realized that you can already kind of do that in the calendar. So
if you go to calendar, you can do that. So we proposed to send the email to this
guy saying that you can already kind of do that in Nozbe, but then we realized that
we can actually improve this feature and make it also available on the project view.
So it's not there yet. We are working on it. But what I wanted to say is that it
sometimes takes us a while to understand what people mean. And sometimes it's just
the question of, hey, we actually kind of have it. And what they mean is actually
pretty straightforward to do and very useful and could benefit many of our users.
So let's dig deeper into it and let's see if we can implement it. So it's always
this thing that we really try to understand what you mean, understand your problem
and understand where you're coming from, and also understand your jargon, you know,
what you're saying. Mm -hmm. say.
The next stage of our process would be, okay, we choose something and then this
feature request gets an owner. And this person is responsible for designing the idea,
like the strategy and the image of how it should look like, how it should work,
why, how it should be useful and yeah so the person responsible prepares a document
the whole document the long document with everything written we have a template for
such a feature request design draft and there are several questions that this person
should really deeply analyze and describe And only once they are ready,
the famous design fight meeting is called.
And, yeah, Michael will explain you because he's one of the nights of the round
table. Exactly.
So every two weeks, we have a design fight meeting. And only every two weeks
because during these two weeks, we work asynchronously using Nozvi, losing tasks and
comments. So we don't need to meet as much as everyone else. Like in most of the
companies, they're just meetings. Everyone else thinks they should. Exactly. Everyone
else thinks they have to meet every hour of every day. We don't.
So we meet for design. We meet only every two weeks. But it's because we're all
busy. The programmers are working. We are a small company and the programmers are
working on programming, the designer is working on designs, and the Design Fight
Committee, so the Committee of Five Nights in the Design Fight meeting,
are preparing feature requests, are going through feature requests, thinking about
them, asking questions, asking follow -up questions to customer support, to some other
colleagues, reviewing all that stuff. And the thing is, Once we meet,
we don't present the feature requests, because before the meeting, everybody has read
all the suggestions, all the proposals. On the meeting, we discuss the new ones.
We try to, you know, see what was not said. We're trying to find edge cases,
which can be really, really annoying, because sometimes you prepare this feature, it's
beautiful, it's, you know, it's perfect. Like the way you've described it, it's, you
know, implementing it like this is going to be perfect. And then somebody on the
meeting is like, yeah, but did you think about this and that? And I'm like, because
of that, we need to have the meeting to discuss the features. And of course, one
thing is that we have thousands of customers. So we want to make sure that every
feature that we implement could be potentially useful to most of these customers.
So not all of them, but most of them. And second thing, people use Nozbe
differently. Some people have 1 ,000 tasks in a project. Some people have five tasks
in a project. So it's like you have to also take this under consideration because
sometimes we have to make sure that in all cases, in big projects,
small projects, you know, big lists of projects that Nozbe works quickly and well in
all of the circumstances. So anyway, back to the meeting. The meeting is we have
the same five people who take part in this meeting and only out of 15 in our
company, only these five people take part in the meeting. But the meeting agenda and
everything related to this meeting are open, accessible in a project to everyone on
the company. So everybody can give feedback, everybody can propose something, and we
can also ask them for up questions. So the people who are chosen for this meeting,
it's based on the Pixar movie, Pixar company from the book Creativity Inc.
by Ed Kastmo. And it's the brain trust. So people who are there are the ones
deciding if the feature goes forward. And the idea is that there is no boss card.
So I have as much say as everyone else. So I take part in this meeting. Our lead
designer takes part in this meeting. Head of customer support, Yvona.
Then Yarek, one of our programmers. And Kamil, our project manager slash tester slash
QA slash everything else the camera is responsible for the application to show up
for every update to show up every two weeks so we all show up there and we
discuss the meeting and then only once we've approved a feature it goes to our
project of features that are approved to be able - ...to być w porządku. - Tak,
i to jest to, gdzie druga rzecz zaczyna. Więc to będzie prawdopodobnie design.
To był Hubert. Prawdopodobnie z pomocy i pomocy z innych osób z drużyny.
On to designuje. Więc on imagina się,
a potem opowiada i designuje. ... nie what new buttons, what new lines of text,
what new icons, what new spaces will be taken by this new feature. And it's not
easy job because, as you know, Nozbe is very simple and it's mobile first.
So actually, he doesn't have so much space to use because it's only a small screen,
yeah? I have iPhone mini, how many things you can, you now squeeze into it.
So it's a process that if I place a small icon here, we have to resign from
something. If we can't place it on the main screen where we should hide it so that
people can find it. There are so many questions and edge cases and complications
coming from the fact that Nozbe is very simple and we want to keep it simple.
And we don't want to overwhelm the user with too many features waving to him and
saying, pick me, pick me. And then, of course, we have to decide how it should
look like on the Mac application, on a web application, in iOS application and
Android, etc. There are five different, totally different views it has to be ready
for.
And then he has to consult with the programmer all the time,
with the front end, with the back end, because it's all connected. So this step
also takes long. Yeah, and depending on the feature, you know, sometimes it's like
Hubert, our designer has to design it and it goes back to the meeting. So we can
discuss the design because sometimes it's a complicated feature. So we need to go
through the mockups to make sure that this is what we want.
of feature scope. And it's the same later,
when we plan the feature for implementation, some features are just tasks and some
features are projects. It just depends how big the feature is. Yeah,
so after design, it's the coding time. And for me, this is the sheer magic because
I'm
and in any way connected with coding. But I tried to understand how it works by
consulting before this episode with our programmers. And they described me.
And now I'm even more full of admiration for them than I was before.
And, you know, he has designed. He imagines how it should look like.
He has these mock -ups or some images ready, and they have to adjust it to the
code that we already have because our application has been on the market for many,
many years. And probably you can imagine that it means many, many lines of code
because the code kind of consists of all the features.
So the new feature has to be adjusted and somehow added to the existing code.
And that's not easy because sometimes adding few new lines has to change the way
that application was structured. So they have to rewrite, re -design what already
exists just to be able to squeeze in this new feature. Because imagine if they
added the patches of new features to the code, it would become so complicated and
it would be like the very unstable. And after several years, it would be total
mess. So that's one thing. Existing code.
Do you want to add something or shall I continue my my admiration for coding.
Yeah, because the thing is that it's always, you know,
it's not always as straightforward as just adding two lines of code, as we mentioned
in the beginning. Sometimes it's the question of removing some code or rethinking how
something was designed before or coded before and changed completely.
So that's why it's never as easy as it might,
I mean, usually not. Sometimes it is two lines of code. But even then,
sometimes these two lines of code affect some other part of the of the app. So we
have to make sure that it really works. And that's why Kamil, who's also doing our
testing, has to always check the whole app if after adding this one feature,
something else, something else in a different place of the app didn't, you know,
blow up. Mm -hmm. Yeah. Another issue I think is really impacting and consuming the
time and the energy of developers is the fact that, as we said, we have five
platforms. Yeah, this is this is one app, but actually these are five different,
I don't know how to say, sections, creatures. Yeah, I mean, we share lots of code
with these apps, but there are still five different apps. Yeah, so, you know,
navigation on Android and on iPhone is different. You cannot have the same things on
this. So the poor programmer has to think like in five paths parallelly.
Also, very often there is some, I don't know, like integration with external
platforms. When the guys are working on the integration with Google Drive or with
Microsoft Teams, I imagine how much work they have to do to integrate the code and
those stuff that the people from Google it with our code. It's also not easy. And
probably that also, yeah, needs a lot of research and getting to know the code of
another application. Actually, Google Drive is not the best example because we are,
we have dropped the integration with Google Drive because Google, so we have
integration with Microsoft OneDrive, with
have integrated we are not going to ship the integration with google drive because
um a google has put a limit on what we can use and they've made it very difficult
for us to use it or they they blackmailed us that we can we otherwise would have
to use their code in our application and this is another there's another sad thing
that we're doing, sad, but not sad, I mean, because we take, we are so crazy
about, you know, crazy,
suspicious, no, crazy careful about your data.
We don't allow any third -party code in our code. So, I mean,
you know, code, yes, if we can read the code and change it, but not third -party
libraries. So libraries where we don't see the code. So Google was forcing us to
use their library without seeing their code. And we don't allow it because we are
afraid that external code from something that we don't know might steal your data.
It's Google. It's Google. They are specialists in using people's data.
So they are, I mean, this is one of, you know, we want to be GDPR compliant.
And to be GDPR compliant, we want to make sure that we know each line of code.
Even if it's a code from some other, you know, a company, we can integrate it if
we can read the code and see what it does. But if it's a library where we cannot
see the code, we are not going to implement it. That's why we haven't, I mean,
probably we will not be shipping Google Drive integration, which is sad and it's sad
for our users, but this is sometimes, again, a trade -off. Like, what is important
to us, you know, your customer data safety or an additional feature?
Yeah, so
The other thing that might slow down the process is the fact that we are a small
team. We are not a corporation with 200 developers where each of them works on one
feature. No, our poor guys, apart from creating new features and adding new functions
on options to Nozbe, they are working on backfixing, on maintaining the existing
structure, infrastructure, taking care of solving the problems that come from customer
support. We received so many emails and issues and problems and questions that they
are busy all the time, so they cannot devote totally into implementing new features.
So that's also something to take into consideration and not getting so frustrated
when we don't follow your suggestions so quickly. Okay, let's take a break and
listen to one of our users happy with Nozbe. And after the break, I will one of
the features that we are about to ship that seemed like a very simple feature, but
it took us months to develop.
When we've been around for about 10 years, our business has, and we've been using
Nozbe for about eight of those years. And as we grew, we kind of got to the point
where I just couldn't remember everything anymore. I'm pretty organized. I would just
kind of keep everything in my head and with post and notes and things like that.
And it just got to be too much. And so I started looking around for some sort of
project management software that could help me have a set up really trusted system.
But really, I just wanted a system where I could know that I had everything in
there. I wasn't going to forget anything. I wasn't going to drop any balls for our
clients or missed deadlines.
We are back. Yes. So I will tell you, actually this, this feature and this email
from this user was our first motivation and spark to create this episode that you
are listening to or watching. We received the email that when you are going to
implement the printing feature, how is it possible? It's taking you too long.
It can't be so complicated. It's just printing. It's just few lines of code. Come
on, guys. I'm really getting frustrated. And then I said, Jesus, we have the best
developers in Poland, probably. How come, how come, if this guy says it's so simple,
how come it's not ready yet? And I see this printing, printing in Nozbe showing up
in various tasks for quite some time now. And,
and yeah. Yeah, our running joke was that we are introducing AI features, but people
really don't want, all they want to do is print their task lists. It seemed like
the printing feature was more important. And yes, we implemented the easy part of it
by just letting you export task list to CSV,
so common separated values format. And we've done that like a few years ago. But
the printing feature, printing to PDF was much more complicated because, again,
we are a multi -platform company. Because when we started thing is, when we started
digging deeper into all the suggestions of how we can print things, we realized that
it's not, the printing is a big, it's a keyword for many things.
Some people want to have a list of features.
Oops. Why do we disappear? We are, I don't know, we are experiencing some magical
things. Maybe the god of printing is taking the advantage. So we have some, okay.
we have disappeared from the recording, so I didn't know why. Anyway, so the thing
is that we are, we want to make sure that you can not only print,
but you can print from any device. So even if you have a long task list of 1 ,000
tasks and you access it on your mobile phone, first of all, we make sure that you
can load the 1 ,000 tasks very quickly, which you can, but Also, you can print them
directly from the phone or directly from the desktop or from the browser. So when
you hit print, we actually have a special server that generates the PDF for you.
And because there is a special additional server, it goes very quickly. So even if
you have a long list, your application doesn't freeze, it doesn't hang. It quickly
generates the PDF. And the PDF, you can print out, or you can send to somebody
through WhatsApp, through email, or whatever. And it's our server. So apart from
creating the printing feature, we also had to come up with this server thing.
Yeah, we have a print server, basically. So we have additional infrastructure just
for this feature. So as you can see, this feature not only requires work on the
app, work in the back end, but also creating a separate infrastructure, additional
infrastructure, which later has to be maintained, upgraded, updated, and all that
stuff to make sure that we can sustain this feature. But again, we are doing it
great. We're doing it once, and it's going to be fantastic, but it takes just a
little more time. Also, our developer, who was working on it, who is working on it,
he also had to modify and improve some of the code, again,
some of the infrastructure to make sure that it goes very fast, it works very fast.
So again, something that seems like a tribal feature. I'm going to just print the
list of tasks. How hard can it be? In our case, it was very hard.
But what we have built, what he has built, what we've achieved here, will be used
not only in this part, but also in some different parts of the future features.
Because again, implementing features the right way is a long -term bet that when we
are working on a new feature, it's going to be easier for us because we've already
done some undermining code for it.
Yeah. So as you can see, now we are at the stage of developing and coding the
feature. And then we need a lot of testing. Yes, we can't send you something that
is not totally tested. We need to find all the possible edge cases, all the
problems that might come up and how we do it.
We first Kamil tests it and then our whole team tested because we want to make
sure we will use it before we give it to you. Yeah. So basically every day we
work on the, on the, what we call it, dog fooding version of the app. Dog fooding
means eating your own dog food, which basically means in the software parlor on the
software world, it means, yeah, you test what you, you know,
you work on stuff that you have built. And this means that sometimes things go
wrong. Sometimes we, something breaks or doesn't work anymore.
But we are brave enough that we can suffer for you, for our customers. We take it
on ourselves to try it. And that's why we have this dog fooding version of the app
that basically updates a few times a day. Whenever a programmer builds a new version
of the app, it automatically wants it automatically wants to be updated.
And thanks to that, we can test it very quickly. And again,
we are extra cautious about customer data. So we want to make sure that if we
introduce a feature, it doesn't break anything, It doesn't delete anything. It doesn't
remove anything. Even though we have backups and all that stuff, we just want to
make sure that nothing really catastrophic happens. So that's why we test the feature
internally in this dog -footing version of the app. Yeah, and we test it in real
life, yeah? We just tested for our work, for our private use,
in different devices on the phones, on computers, on tablets. so we are trying to
do it.
so that quickly they can keep improving, iterating on the feature. Yeah, I love the
situation when someone says, oh, I have a problem here and here. And then Kamila,
our tester, said, I cannot reproduce it. Can you tell me how you broke it? Yes.
Okay, so first I opened this, then I added the, I don't know, a new tag,
and that was in my private space. And Kamil said, okay, I'm trying to do the same,
but I don't reproduce it. And it's always so difficult when someone breaks it and
they forget how they how they broke it. And Kamil has to find out what to do to
break this feature. One of my favorite features of workers, as people know here,
I use iPad as my main computer. So my favorite features of the iPad system is that
I can very quickly very quickly create a screen recording. So I create a screen
recording and then later I attach the screen recording to the task directly to
Camille. This way Camille can see what I clicked, how I clicked, and how this
happened, which is always much better than just explaining to him how it went down.
And especially that sometimes, as you said, I forget how it happened. But when I
get it, then I'm going to record the screen. I'm going to do it again, and then
you can see the glitch. So we do thorough testing,
and then after we decide the feature is ready to be shipped to users,
we still keep it for another week. We have another buffer of a week so that we
use it as a ready for production feature for a whole week inside of our company to
make you know, nothing really bad happens. And then, of course, then of course we
ship it and usually it's fine, but sometimes you, our customers say, hey, this new
feature breaks here and here. So even then, sometimes what happens is that you find
a way that, an edge case or a bug that we haven't,
you know, found. But we assume that during our testing, at least the critical bugs
have been covered and the, you know, the mission critical things that work.
And that's also, that's when if you were the source of the idea and if it was
you, if it were you who suggested the feature, that's when you receive an email
from our customer support. Hi, thank you for this feature. Now it's available and
you can use it and test it. So, yeah, that's when you can feel that you really
contributed to Nozbe application. Yeah, we are very thorough about this.
We really want, because with every feature request, we not only write the request,
but also the email address or the user ID of this user,
later our customer support goes through all these comments and sends individual emails
to each customer saying, hey, your new feature, your feature you suggested is already
there, which sometimes is like, you know, sometimes it's like a few weeks, sometimes
a few months, sometimes it's a year or more. So sometimes people are surprised.
After a year, you remembered?
But we don't have to remember. We have that in our trusted system in Nozbe. So
that's why we use Nozbe because we don't have to remember. We know that you asked
for it, and we want to get back to you on that. Yeah. So I hope we explain the
whole process to you thoroughly and that now you understand how much time and how
many decisions it takes to introduce a new feature and that we cannot implement all
of the ideas that are sent to us, but we do register and we do take them into
consideration. So please continue to send us your ideas, your suggestions, and your
problems, as Michael said. And please don't be frustrated. Don't get annoyed when we
don't implement it right away, because that's really complicated. And we are a small
team. Yes, but now that we had, I mean, I still encourage you to check if you
haven't, our A .I. Webinar where I explained our upcoming,
I mean, coming now, our AI first AI features. And again, we ship these AI features
as an encouragement to our users to give us more feedback of how they want to use
AI with NOSPI. Because we have some ideas and we are testing some ideas of what we
can do to develop the AI integrations. But I'm sure you have much more.
So that's why we'll keep on listening to these now that the first AI features are
shipped. And the same goes, as you mentioned, with all the features.
Just, you know, sometimes we don't implement something because it's not the right
time as well. It's question of timing. We have, for example, other things lined up.
And as Magda mentioned, we are a small team. So we will have to prioritize which
features go first, which features go later. Sometimes a feature is a low hanging
fruit, so it is just a few lines of code and we think it's useful, so we do it.
So sometimes one feature goes implemented quickly, sometimes, you know, the one like
with the printing, it takes, you know, many months to be shipped. And also sometimes
we don't implement a feature because we are just, we feel strongly against it. So
one of the notable examples has always been over the 19 years of Nozbe,
there are no sub -projects, and they will never be in Nozbe. If you want sub
-projects, go somewhere else. Because we believe in a flat structure of projects,
we can group projects together. So this way we can give you some organization. Also,
inside a project, you can have sections of tasks. So so we give you some
organization, but we like the flat structure of projects, of task lists, and we also
have a checklist that can be attached as a comment to a task. So you have
checklists as well. But again, these are checklists. These are not subtasks. So we
don't have sub projects. We don't have sub -tasks and probably we never will, we
never will, because this is not how we roll. This is not the Nozbe way.
this is against our values of simplicity. And if you really need sub -projects, you
can just imagine the sections are sub -projects. During my consultations, when I see
someone is really into sub -projects, I said, yeah, of course, we have sub -projects.
These are sections, and they are very happy. It's just the naming. Yeah, it's just
a naming, and it's also,
but what we will not offer, not offer, for example, as this tree of tasks and
projects. Yeah, like you can do on the computer folder, subfolders, up folder, and
then you get lost in this long. So it's again, the question of some things we
stand for, we stand against, of something of, of, of, but mostly what we wanted to
show you in this episode is we are for you. Like, we really build this application
for you with your input. So you are co -creating this application. And we never
ignore anyone's suggestion. Sometimes we just can't introduce them or it's not in
line with our values or it's just very complicated and we need time.
Yes. And we are regularly going through all these suggestions. We are also because,
as I mentioned that even the design part is done in Nozbe,
in Task in Nozbe. So we also reference, you know, we link tasks in the comments to
the task from the customer support, from the suggestions. So very often when we are
designing something, we are going through your emails. I mean, not emails, but your
suggestions, the ones that we have gathered in comments, to understand you better, to
understand what you mean, as I mentioned. So really,
developing an app for thousands of users, for thousands of paying customers is
challenging. And especially with a small team, but it's also rewarding because that's
one of the things which I like with my job is still after 19 years, is that it's
challenging to figure it out, to really make sure that you understand, that you come
up with a nice, smart, simple solution. Because really,
simplicity and complexity are two sides of the same coin. So if we make a feature
simple to use for you, it means we have to figure out the complexity behind it to
make it seem simple. If, because some other companies do it the other way around.
They decide, I'm going to throw you a form and many, you know,
complicated things because they thought, I'm going to make it simple for myself, just
throwing all the complexity to my customer. This is not how we roll. We focus on
solving the problem for you. So you see a simple interface while we figure out all
the edge cases, all the problems, all the complexity behind it. So we take the
complexity side to make sure that you get the simplicity side. That's how we roll.
Exactly. So now, after what, 50 minutes,
we hope you understand and that we are all good in terms of your future requests
and suggestions. And we have an episode where we can point to if somebody says,
hey, it should be easy. Listen to our episode. You'll transparently see how this
sausage is made, how it's done. So thank you so much for listening, for tuning in.
Thank you so much for supporting us, supporting Nozbe. We just celebrated 19 years of
Nozbe, 19 years in business. We just celebrated our first AI features. So we are on
the role and there are many cool new features coming still this spring. So stay
tuned and thank you so much and thanks for being with us. Thank you, Maddoch.
Bye, bye.
Thank you for being an amazing listener of the No Office podcast. Every other
Wednesday we meet to talk about productivity and hybrid lifestyle because we believe
that work is not a place to go. It's a thing to do. It's a special gift only to
No Office podcast listeners. When you sign up for Nozbe using this link, Nozbe .com
slash podcast, you'll get 30 bucks of credits which you can use to upgrade to Nozbe
premium. Nozbe helps thousands of smart business owners and their teams get their
professional and private life organized in a single app, in a simple way. And Nozbe
is free for up to three active projects and three people on your team. So start
today and claim your free bonus credits, which you will later need to upgrade to
unlimited projects. Once again, thank you for being an amazing listener. Thanks for
your support and for spreading the word about our No Office podcast and Nozbe. See
you and hear you in the next episode and in the meantime claim your bonus credits
here.