Don't cram plenty people on Zoom fluorescent lighted office all day long.
You know, you probably are going to work from home.
Hello and welcome back to No Office, a podcast about work technology and life from a remote company perspective.
My name is Rafał Sobolewski and I'm joined by my good friend and CEO of this remote company.
We call our search hashtag No Office company.
and the company is Nozbe and CEO is Michael Sliwinski.
Hello Michael, how are you today?
- Hey Rafal, good, good, good.
We're recording on a different schedule.
Morning our time, so probably our American friends
are asleep right now, but we decided to readjust
our, well, our hours of meetings.
We'll talk about it today in the episode.
And yeah, I'm good.
I am already kind of feeling the Christmas spirit
And this is my last day of work, probably.
Like, you know, today is Thursday when we record it.
And then tomorrow is Friday, the Mighty Friday.
So one Mighty Friday, one good review,
and I'm off to the races.
Yeah, that's nice perspective.
I don't have so many free days left in the series,
so I will continue to work next week.
But yeah, I'm good.
I'm glad we changed our recording schedule
so we can have coffee together.
Yeah, and this is episode number 32.
Like 32 gigabytes of RAM memory
in my brand new MacBook Pro, which is not here.
It was supposed to be here by now,
but yeah, apparently something went wrong
and the finance part of the Apple company
didn't start the payment process.
- Oh man.
- Yeah, and now it's moved to be delivered
between 31st of December and 4th of January.
- So no ho ho ho for you, man.
- Yeah, and I had interesting experience
calling Apple support.
On Tuesday, it was 14th of December.
It was the last day of the delivery window,
but Apple gave us, yeah.
So I called them and I had to wait like 30 minutes on hold to get to talk to someone.
Your call is very important to us. Please wait and just wait and just wait.
Yeah, and two things about it. One good and one bad. The good thing is that they really put a nice music there.
when you're writing. It's not like some shitty melody.
It's really just normal music, like the kind of music they put before the
Apple keynote starts when you open the stream.
So they have a whole Apple Music playlist for you.
Yeah, something like this. So the experience is better than normal waiting on hold.
gave me an option. If you want to talk in English, you can press one and connect immediately.
So I did that. And the English person told me, "Oh no, it's the Polish market border,
so I need to switch you back to the Polish person."
And push yourself at the end of the line.
Exactly. Probably, yeah.
Or as they say in Britain, "Q, at the end of the Q."
yeah yeah so that was the experience yeah and now that the Reveri window is
moved to to to the newer new years Eve this is really weird like we ordered
almost at the same time actually you ordered earlier yeah one week earlier
then Radek and MacBook Pro both went through my father our finance guy both
were paid almost immediately and I mean the payment data and everything so there
was really no glitch on our part. They have no like because because Apple is
nice company and they charge you only when the product is ready to ship yes
they are not the shitty company that way you pre-order something and they charge
immediately and they ship it in three four months okay yeah so this is this is
nice but apparently something went wrong or I don't know like that the lady on
on the other side was very nice but couldn't tell me what was the reason but she just contacted
yeah she just made a ticket for the finance guys. So just to tell you that I really know what you
feel because if you remember I felt the same thing last summer I mean this summer when I was
getting my iPad pro it was already like way past the delivery window when it arrived
I ordered it in mid-June.
It was supposed to come in the second week of July.
And at the end of July, I was going for a short trip to Germany.
And one day before this trip to Germany, at the end of July, my iPad Pro came.
So it was really like last minute before my two-week trip.
And I was so happy that they managed, but I was so frustrated.
I called them also several times, I remember, on the Apple support, and they couldn't tell me anything.
They just said, "You have to wait.
That's it."
They didn't even tell me that, that there was just some glitch
between finance or whatever.
They just said, "You have to wait."
But I think in my case, it was the problem with the iPad Pros
being just backlogged.
There were just many orders and they just didn't keep up.
But they should have updated the page, but they haven't.
It was the 20-something of July, and it was still saying on my
page, "It's going to arrive between 13th and 17th of July."
July so yeah so I really know what you feel because and especially you know
when you want your new toy you want your new incomplete the new thing just like
in my I've already sold my iPad Pro with magic keyboard exactly you see so I my
only my only mobile computer right now is this iPad mini so so yeah it's a
tricky tricky thing so I haven't sold my iPad then I anyway my iPad went down to
my daughter and she loves it of course there she has the iPad Pro 11 inch with
magic keyboard and with Apple pencil so she is in love with this thing but yeah
so this is what happens when you order stuff about selling iPad Pro I put it on
sell together with magic keyboard as one bundle one bundle and it was hard to sell
it once I put it separately as separate offers then it after two days it was
That's interesting. So apparently people prefer to just buy the iPad or buy the Magic Keyboard, not both.
Which I totally don't understand because really I've already said it on the show several times.
I'm in love with this machine and I'm in love with the Magic Keyboard. This is so much joy, this new iPad.
And I just like this keyboard wants me to type.
It wants me it wants to be typed on. It's like it's tickling my fingers.
fingers. It's so good. I really love typing on this thing. I really love my Magic Keyboard for iPad Pro as well.
Anyway, I'm still getting prepared to update my setup to waiting for this MacBook Pro.
As we talked in some previous episodes, I was counting on this universal control feature in Mac OS
that Apple is supposed to ship this fall. But now it's late and it's officially
On Apple's site it says it will be shipped in spring 2022.
So it really sucks.
Because I wouldn't be able to test if my assumption that I could use my iMac as my second canvas,
I wouldn't be able to test it until spring.
So yeah, kind of sucks.
Yeah, and I was starting to figure out what do I need for my MacBook Pro to use it here
in my home office, what do I need to connect to it? And actually, I need to have a USB-A port
to connect the camera via KAMLINK and Ethernet too, because I want to be on the cable while doing
live streams. Not because of the internet speed, but because the delay is not that much on the
cable. I can use this full HD monitor that I have to use. It has USB hub via USB-C, so I can connect
it. But I have only one USB 3.0 with USB-A type port to connect the camera, and I have nothing to
connect Ethernet. So probably I will need to buy an adapter and there's no official
adapter from Apple available from USB-C or Thunderboard to Ethernet.
Yeah, but the ones that are on sale, I have one from Ugreen. It's fantastic. It's very good. I
have two of those and they work very well. Yeah, they work very well, but I saw the one
from Ugreen at the product page they say that this might not work very good on macOS Monterey
12.0 and it should be fixed in the future updates. Well, so I can tell you that from my experience
the adapters that I have work very well both with the MacBook Pros, but not Monterey, I haven't tested
Monterey, I don't have a MacBook Pro with Monterey here, and also with my iPad Pro. So it's my regular
adapter if I wanted, for example, just connect wired to my router to just
do some diagnostics, for example. So I just take my iPad, connect it with this dongle and the cable,
and it works very well. So no complaints on that side. So you don't need an official Apple
branded. Yeah, but I would always want to have an option. Okay, but we will see how it
how it was actually i have i have a usb-c to digital audio video also with
usb-a and hdmi port so maybe i can somehow use use that
and have some adapter from yeah but anyway i still i still need to buy an
adapter to eternet there you go so uh dongle town episode
number talent and when i was researching like
4k monitor options. Only Philips has monitors with Ethernet port.
They're not really very popular, the ones with the Ethernet port.
And monitor options are really not that great.
We will see. I know it's not the purest thing but my wife is really
happy with her 27 4k display. It's pretty good.
I'm thinking that the 4K with 27 inch wouldn't be awesome,
but would be good enough to not to be sharp enough that my eyes wouldn't
see any difference.
Yeah, and the one that we have, I have a Thunderbolt cable to it.
So I just connect it to my iPad, and it both charges the iPad
and just mirrors the iPad screen.
And of course--
Do you remember which model you have?
Yeah, I'll send you the--
But it was the one recommended to me by our friends from our Nozbe team,
by Leon and somebody else. So I just went with their recommendation.
That's it. Still waiting for my beloved MacBook Pro.
All right. This is the suffering of technology enthusiasts.
OK. Last episode, we talked about how we can set our design flight meeting
and go more async with the communication about design.
we have some more changes in our meetings schedule.
This is what I like about the way we work. We have these quarterly
off-sites, the quarterly meetings. And then every quarter,
because of these meetings and because of the feedback that we get, we do change
some things. We do make some adjustments. And I like making
adjustments every quarter instead of every year because you just forgot
how it was if it's just a year. So every quarter is for me the best
feedback loop because it's already like three months in, which really three
months is not that much of a time. But it's long enough
but it's short enough. Every quarter, a part of my quarterly
review is to review my weekly schedule, how my week goes, if there is
anything I can improve, if there is any meeting or any other
time slot that I'm using wrong. Or for example, in my case, here where I live in autumn and in spring,
it's very nice to go out to do some running in the middle of the day. Like it's 2 o'clock,
like at 2 p.m. because it's the warmest. Yeah, like in winter season. Yeah, it's the best time.
I know early morning is the best, but not in winter. In winter, it's just freaking cold.
So really from autumn through winter to spring, the best time to go out for a short run just to,
you know, do some sports, it's in the middle of the day. That's why I really like to readjust
my schedule so that I can have like at 2 p.m or 3 p.m, sometimes one hour to just go out,
go for a run, go back, take a shower and continue working. So yeah, so based on all that and based
on your complaint that you had too many meetings on Monday, which was true, we decided to completely
change the way we do meetings. Like not completely. Adjust them. And now we actually do something which
we always said we wouldn't do, but we start almost every day with a meeting. So we have a meeting,
in my case I can say that I have a meeting every day, Monday through Thursday, at 10 30. So 10 30
to 11 30 usually. Usually they're just one hour, maybe a little bit more, but usually one hour.
So this way, in the beginning, I have my breakfast. I get my kids to school, I have my breakfast,
I have some warm-up time, I can prepare for the meeting, then I have the meeting. So it's really
good to have this time to prepare for the meeting because meetings should be prepared. And then,
after that, at 10.30, I have the meeting. On Monday, I have our director's meeting,
so our leadership meeting. On Tuesday, I have marketing meeting. On Wednesday, I have our
business analytics meeting with Tom and then on Thursdays, every other Thursday, I do this. I have
a meeting with all of you guys. And with Rava, of course. And then on Friday, no meetings because
Friday is Friday, it's mighty Friday. So come on. And then at 12, after the meeting, I have some time
to calm down and relax and maybe brew another coffee. And then at 12, from 12 to two, I have
I have a constant block of core hours.
The core hours concept, I wrote about it in my book
and we'll link in the show notes
and we also talked about it with Radek on the podcast.
So it means every day from Monday through Thursday,
so four days a week from noon to two, two hours straight,
I'm working in focused mode.
I have one topic, each Friday I choose a topic
and then through these days I work on this one topic.
And then from 2 p.m. onwards, I might go do some sports.
I might have additional meeting if I want to.
I might have a feedback time for my Nozbe team.
So after 2 p.m., I decide what to do.
So very often after the core hours focused session,
I go for a run or I do some other sports,
and then I get back to work to do some feedback
and get back to the team.
So this way, my week is better structured, I think.
- I had a very similar schedule, weekly schedule.
I've also planned this core, like core hours,
but I don't plan like one topic for the whole week.
I just plan two free topics per week.
So I want to make sure that I have appetite only
for like one or two core hours per topic,
on today's per topic. So I think I want to try this if it motivates me to really deliver
something that already adds value and can be asked for feedback and move forward.
So this is what we learned about... It actually works for our product development process,
we will talk about in a second. Having this, setting this appetite, it really makes you,
triggers you to make good decisions to deliver something.
Exactly. And so that's why it's really like I really recommend evaluating your meetings
on a quarterly basis. Just make sure and Rafał, I think you're happier right now with the new
meeting schedule that you don't have the Monday completely swapped with meetings, right?
Yeah, yeah. I think with current schedule it's like perfect. Again, we have that many meetings
that we have appetite for. It's not too much. It's less than we used to have.
I think that's really nice because it leaves a lot of space
for first deep work in core hours and second for asynchronous feedback.
We are creatures of habits so it's really good to structure your week,
to really think about this. I think I stole this idea from Michael Hayat, the
the idea of the ideal week. So how would my ideal week look like? And of course it's never ideal,
it's never perfect, but having this framework helps you know what to do.
Yeah, this week is totally a mess for me because first of all I had a booster shot of vaccine.
So I was a mess on Tuesday and Wednesday, and I got some cold.
And actually, my feelings, I also got some cold, but we do some anti-gene tests. It's not COVID,
so don't worry. It's just a normal cold. So yeah, it's not perfect. I wasn't able to do
core hours on Tuesday, but still, the schedule, you should...
it's good to have this perfect schedule that you are trying to optimize for, but if you don't
achieve that, that's fine. Just move on. Only this week, it was the first time. I haven't done
Corobers in a very long time, and I missed it. So this week I tried, and for example on Tuesday
I was in such a procrastinating mode. It was 12, I haven't started yet. 12.30, I was still doing
some feedback and some other things that I wasn't supposed to do. At one, I was still doing that. I
was like, "All right, I feel so guilty now. Let's drop it. Let's focus on the core
hours." So I started really late. I started at one o'clock, one something,
but then I pushed through and I worked until, I think, 3 p.m.
on the core hour. So I did spend two hours on this on the topic,
but it's like you have to still get back to this muscle memory, to this
habit of, "This is the time to start. Let's go. Let's do it."
And it's hard. That's why I really want again start next year doing core hours regularly so I get
back into this habit of delivering weekly some really good output in my core hours.
Wow, we are already recording for 22 minutes so maybe let's take a break here.
Let's give the microphone to Mike St-Pierre.
Yes, because no of his podcast is sponsored by Nozbe teams, a to-do app that helps small teams
do great things. Let's hear what Nozbe customers say about the product.
We tried different project management tools for the first couple years when I was with
the organization I currently am, CCMA. And then we realized that we just need really
one place where we can communicate, where we can share projects, where we can think
in written form, where we can give each other feedback. So we tested a couple of different
things and eventually we settled with Nozbe teams and it's been really fun to see the software mature
and just get better and better. The data security, I know the company is totally committed to
improving the product. For us, it's simple. We have some members of our team who are very tech
savvy and some who aren't as tech savvy. So to find one tool that actually is usable for all
those is not easy. We did dabble in a couple of competitors and they were just too much,
too complicated, too many features. What our team needed was something simple, reliable,
trustworthy, something that was fun and attractive and enjoyable to use. And so Nozomi Teams has
really fit for us. It's met that sweet spot. It's reasonable. We're a nonprofit. And so the price is
right. It's easy to add members. I just added somebody yesterday. It was no big deal. I think
I went to the five person plan to six. It was not a big deal. So that's nice because it's flexible
for us. It just gives us a place to park everything and it works for us. So we don't want to be
emailing within our team. We're not perfect at that, but we want to cut down on that. We want
to cut down on interruptions during the day. And so I'll try anything that will help accomplish
those two things. So for us, Nozbe teams really fits that need that we have as a small team.
All right. That was Mike St-Pierre, our customer.
If you go to blog.nozbe.com on our blog, there is my full interview with Mike
about his productivity summit that he just recently launched. And you can still get the
the recordings of it, it's really, really good.
And when you pay for it, the payment goes for good causes.
So make sure to check it out.
But like when he was saying that about Nozbe teams,
and I just asked him a simple question.
I said, Mike, can I use it as a testimonial?
It was so authentic, it was fantastic.
So I just, we just cut it out from the interview
just to put it as a testimonial.
- Yeah, yeah, that's really great.
We have more and more of those customers
who agree to record for us testimonials.
So we can use it as ads inside podcast.
That's really nice.
And it's just so much better to hear from somebody else.
Like, you know, we are not the ones selling, you know, Nozbe Teams is the best.
We know it's the best.
We spent our whole life building it, but it's just so much better when somebody else recommends
it.
So, yeah.
Today, I wanted to talk to you about our product development process as we kind of talked about
it in episode 13.
it's called no roadmap.
- Yeah.
- But I want to add to it the things we learned
from with this time, it's like 10 months
from the episode 13.
I'm really glad how it works right now.
And I was procrastinating on writing it down
as our product, this product dev process
as a formal document in our wiki.
- Okay.
if I want to also have it somewhere on our help page
or maybe as a blog post to be transparent with our users
so they know how we work.
Yeah, and I was procrastinating on it.
So I decided, okay, let's talk about it.
And based on that, it will be much easier
to prepare those kind of written forum content about that.
As we said many times on this episode,
transparency is very important in no office company,
but also transparency to our users, to our customers.
So this is why I want to do it.
Okay, so basically to remind you,
we work in five weeks cycles.
So that means that every five weeks,
we have a retrospection with our development team
and designers, and we have a retrospection,
we plan the next cycle, what we're going to do. And that's the whole planning. There is no
roadmap. There is just product vision based on those commandments. We also talked about it in
previous episodes. And every five weeks, the development team has a retrospection. So every
five weeks we do some small improvements of the way how the process works and with readership team
like you, Ivan, Adam, Radek, we plan what are the priorities for the next five weeks.
Yeah, as you mentioned we have the portfolio of options so we have you know basically tasks with
descriptions of features we want to do maybe eventually in Nozbe teams and because of that
we can choose from this portfolio of options. And because we plan every five weeks, so every cycle,
the good thing about it is that every five weeks we also incorporate new feedback.
So this way, there's a trick for you, our users. Write stuff to us. Write us feedback,
which features you would want in Nozbe teams and why, and give us the whole story. Not just,
I want this feature, but I want this feature because I want to work like this because my flow normally is like this and
just give us the whole spiel, the whole example, even give us an example like of a
real project in your company, how you would do it and which kind of feature would help you
or you think would help you get there faster. This way we can evaluate it and this way
every five weeks we can choose from this portfolio of options
based not only on our gut feeling
and on our vision for the product,
but also based on the feedback from customers.
If we see a customer pushing,
several customers, not one customer,
but several customers pushing for some features
or pushing for some direction,
we need this and not that.
Then we see maybe we should reprioritize,
maybe something we thought we would build later,
we could build now,
And then that other thing could go for the next cycle.
So really, this gives us the flexibility of not having
a set in stone roadmap for the whole year or beyond,
but just choosing from the portfolio of options
and choosing and filling the room
to see what people really want,
what our users really want, what they really need.
Yeah, and if I go through our features request products,
when we gather this feedback,
like the most desirable features.
The most of them are already implemented
or being in the works.
When I do a planning,
before I ask you readership team for feedback,
I also review like this feature request project.
I review support tickets, project lesson support tickets,
if there is something important there.
And during the cycle,
sometimes I got asynchronous feedback.
feedback, for example, for Livona,
oh, Rafa, this is important.
Let's make sure we plan it for the next cycle.
And then I have this special tag that I mark this task with.
So once I prepare input for you guys
to give me feedback on what's important,
I can point you to those tasks so you can make a decision.
And yeah, and everyone in leadership team
gives me two, three top priorities.
I review them. I need to see the holiday plans for our development team for the next five weeks to see what appetite we have available to spend.
How many work days do we have?
you the these priorities you gave me and see if they are ready for implementation.
So are ready for the developers to work on or they need some shaping up. So design
path. So we have like dev path and the design path. As we said, we really don't need this
load map or backlog because what we learned that important topics always come back.
Yes, they do. And you know, we really have, I'm really proud of our customer support team, our customer
success team, now we call it. Really write to us, we respond very quickly, and we do listen to everyone.
It doesn't mean that we will give you a response, "Yes, we'll do it now!" But we do listen.
And that's why, as you said, things resurface every time.
But especially, and this is the best part, so not only the integration of five cycles.
Remember, we ship our app every week.
we have shipped 45 versions of Nozbe teams in this year, right?
For this?
Yes, yes. 45, I think.
Yes.
So we ship every week.
So the improvements are coming up all the time to Nozbe teams.
And based on these improvements, very often we get new feedback from customers.
And that's what I like about this cadence.
We ship something, we get feedback.
It's just fantastic.
It's just so quick.
it's so much better than preparing a feature for half a year
and then announcing it.
And because of that, everything has changed.
We don't do versions, like version one,
version two, version whatever.
There is a version of year dot number,
and number of the week, and that's why we are right now
on version 2021.45 of Nozbe Teams.
And also because of that, we announced features
a little bit later. They have already been shipped.
People have already been using them.
We already got the first feedback, and then we announced
the feature on our product blog, on our blog.
We do it a little bit later.
And by the way, just a heads up,
the multi-team feature is a killer.
People really love it.
We already have several customers using multi-teams
and using several premium teams on their accounts
because they see that they can divide the work
in personal style, the different departments and stuff.
So it's like the multi-team feature, man.
We just analyze it.
It's a killer.
The one main thing we learned from doing this kind of process
for almost a year is that we really, as always,
if it's possible, and very often it is,
we start very cheapo with the feature.
For example, we usually set one week appetite
to have for front-end and backend developer
to prepare the basic version of the function we shaped up,
but we shaped it up on really high abstraction level.
We just shaped up what should be possible to do by a user,
how user flow looks like, but not UI.
We don't, at this level, we don't shape up UI elements yet.
We just give it to developers
and then they figure out how to do it, how to prepare something functional for us to
test on dogfooding. This is really great because often it happens that after this, we just
say, "Huh, we test it, use it for one, two weeks and see, huh, this actually really adds
already value. Let's ship it and then improve it later." Or maybe, "Okay, to ship it, we
you will need just a small improvement to make it shippable.
And it's one, two days of work.
So the developer who developed it,
usually in the next cycle will find some spare time
to finish it up.
And because they are owner of this topic,
the developer, they are very motivated
to deliver it to the shippable state.
That's a very good change that we did.
That every feature decided for the next cycle
has the feature's owner.
One developer owns the feature.
He's the CEO of the feature.
This person is responsible for the feature.
We have one status task.
They mention us in the task,
and this way we can really see the progress.
In the status task, they report the progress on the feature.
plus of course they prepare other tasks in the project. Every feature has a different project in
Osmo Teams. It's amazing. I think in every leadership book or every management book,
they repeatedly tell you, "Ownership is key." If somebody feels like an owner, they feel differently
about things. It goes to things, it goes to people, and it goes to concepts. Really, if a
a developer feels like an owner of the feature, CEO of the feature, they really take good care of it.
They really care about it. They really ask for feedback. They really feel responsible for delivering it and feel proud when it's shipped.
So it's like the whole mix of feelings of being an owner. And I think this part is really amazing that we have that.
And I'm really glad because my effort is no longer needed
during the cycle to giving a feedback and make product decisions.
Because we make decisions after it's shipped to dogfooding, only then.
And at the beginning of the cycle, we just have a kickoff meeting where me,
designer, and two devs, back-end and front-end, or only front-end or only back-end,
depends on feature, but one of them always is the leader, the CEO of the feature.
And just we make sure that this Shaped App document, usually
comment in the Nozbe team's app, that we are all on the same page
and that the project team and the owner
of the feature understands what needs to be done. And then they are
on their own and they can make a product decision, they can cut the scope, etc.
Yeah, and many times they just learn how to design UI based on the components we already have in the
app. And if we decide that UI is not good enough, then we ask Hubert, our UI designer, to prepare
specs to improve it. But that will be done as an improvement later in the future cycles.
But again, this is the best part. They first built with the blocks that we have.
So it's like building with LEGO. You first build with something that you have,
and then later you see it and you're like "ah, yeah, it could be improved, it could be a bit slightly better,
you could do something here and use a different block, or maybe design a different block or whatever."
So it's like you build with what you have first, and then later you improve upon it.
Many times we just ship to production like this cheapo version, because we decided it already adds value to our users.
But sometimes it requires more work.
For example, we have on the coding features like team comments,
or we change the way on the coding how repeat tasks works and comments inside of them.
But we decided it requires more work to be shippable,
but it hasn't been prioritized yet.
Or, lesson three, when we had design fight meeting, we discussed time needed feature.
And this is the kind of feature that really requires UI work first.
It's not possible to implement it Chippo.
Our Chippo approach is not applicable for 100% of things we can do,
but once it is applicable, it works very well.
One of the things that we discussed during the satisfaction and the quarterly feedback loop,
we decided that we should use the Chippo also for design.
So sometimes we should implement a very Chippo feature
just to see where it goes before we actually design it.
So there's one particular feature.
I'm not gonna mention it right now
to not to get everyone's hopes up,
but there is one particular feature
which I wanted to have implemented quickly
on our dog foodings, so just for us,
just to see if the basic premise,
The basic mechanism of this feature would actually work if this is something that would change our
habit, change the way we do stuff, before we polish it out. Just to see if it works.
Because I was just tired of just designing it and thinking about it in abstract, in theory.
So we decided that we should also have appetite for these kind of experiments, just to launch
something that we might not ship at all. We might just take away from us back, you know?
But to launch something internally just to see where it goes and to see if it's really something
that we would miss if we take it away. >> But as I mentioned, this repeat tasks
and how comments appear in the recurring tasks. >> Yes.
>> This is the perfect example. We really spent a lot of time of designing how it's supposed to work
better and we cannot find a final conclusion. We implemented some
cheapo assumption and we learned from this. We don't like it. Yes, we don't like
it but there are aspects of it that we like it but as a general we
don't like it so it's not not shifted. This is really great
where we can have one week or two or three days appetite to just
explore it. Once you can click physically see it working, the basic concept, then you learn so much
more about that and you can really make further decisions more easily. There is another thing that
I wanted to discuss with you, Rafał, which I think we haven't discussed, so you'll be surprised.
On recent QoS meeting, QoS is our quality support meeting.
We'll discuss it probably in the future.
But the idea is that I get lots of feedback
from the customer support,
like what people really want,
what people really are struggling with.
And the thing is that, for example,
Nozbe Teams app is already past the point
that it's a very usable app for us.
So it's already very usable app for us.
We've been using it for the last two years
from the very beginning, and we suffered through its shortcomings.
But now we don't have that many shortcomings, like our team.
But there are shortcomings that still are part of the vision of the product,
but there are features which we wouldn't use so much, but our customers would.
So they keep on sending us this feature request that, in our case, not really that necessary,
But we see the point. We see that it makes sense in their context, for their industry.
So we would need to really, every cycle, incorporate more features requested from customers,
features that might not be so interesting for us.
And I was thinking that maybe with that, we could think about expanding our dogfooding program.
So to have three steps. Have a step of dogfooding for us. This is our app with all the
dogfooding stuff, so they're just all the cutting edge. But then if we know we can ship
something to customers to show them, we could have a dogfooding for customers. And these customers
could, the idea is this, they would have normal production app, but they could explicitly,
this one app, not their account, but this one app, or maybe their account, I don't know.
But they could switch to tester mode, because some of our customers have expressed this thing.
They would want to test early features before they are shipped.
So we could enable them and we would tell them, guys,
these are not features that, this is not the final state of the features.
These are experimental features.
So really experimental stuff.
Yeah, the things might change.
The things might change or might be taken away from you.
Yeah, like Couple does with beta.
Exactly.
So this way we could have a dogfooding for customers
because then, for example, we can tell a customer
who requests a feature for, let's say, their industry,
and we think it's a very good general feature for everyone,
but the request was from them, we can tell them,
"You know, man, it's been shipped to customer dogfooding,
So if you switch to that mode, you can test it out
and let us know if this is what you wanted,
if this is what you feel.
And this way they could test it
before we ship it for everyone.
- Yeah, like we could have it.
I would call it just a beta version
because like as Apple showed us in beta, things might change.
It's not like the-
- I mean, yeah, exactly.
Like this summer in the beta version,
there was a big woo-ha-ha about Safari and stuff.
and they have really iterated on it,
be based on the customer feedback.
- Yes, and it proved that the process of beta
works actually very well.
- Exactly, so I think next year,
this will be our time to really think about it
and really design this kind of beta program
for our customers.
- So it's like, we already talked about it
with the development team,
because it would add some additional effort
to our weekly release schedule process.
- Complexity.
we really need to make sure that it's done, that our weekly release schedule wouldn't be hard.
But probably it will start only on web first and later on native apps. But yeah, this is something
for the next year to improve. I would also like to improve transparency, as I said at the beginning
of the segment. And I want to make product changelog, so our release notes, to be more
user-friendly and more marketing-friendly. So we can actually have those announcements of features
earlier. Because what we learned for almost two years of shipping Nozbe teams,
we are really, really good at shipping because we shipped 45 versions of Nozbe this year.
So we are pretty good at it.
Like finally, because in Nozbe personal,
it was the whole process when, yeah, we, it was, yeah,
it was, it was a mess.
Like to ship a Nozbe personal update,
like it was the whole week for me to work on.
Yeah.
I couldn't work on anything else.
And what we learned from this,
we implemented in Nozbe teams process and it really, yeah.
I really like how it works.
So yeah, and I think I could slowly start improving this product change log and even incorporate some stuff that we have like this in this beta channel.
We would have or we are testing on DocFooning and we are comfortable with sharing this but we are working on this.
I was wondering, maybe I can help you with that. Maybe we should really host the change log.
I see many, many companies, many small companies, like ours, they do that.
more transparent and then maybe as we mentioned like we have already this new
new new new segment in in Nozbe teams so you can see you know the latest block
posts related to Nozbe teams in the in the feed so you can you know read about
new features and all that stuff but over there we want to add this additional you
know changelog so people can see yeah what what happens is the last version
and this way they every week they can read something new in the app and not
somewhere on the help page somewhere else. Yeah, yeah, and I was thinking like
because currently we just have release notes with like simple points. Yes. The
name of new feature but maybe I could add to it like one sentence, two sentences
how it can be used or maybe even a screenshot or something. Yeah. Yeah. We
will see. I need to shape it up and yeah I want to do it like during this
holiday season because I would have some days to work on. So that's our
lessons learned from one year of using this product development process.
Actually it's based on ShapeApp by BaseCamps but we adapted many things to our needs.
Yeah and but I think one of the also takeaways is the lean
manufacturing. Keep improving the process so make it really effortless
so that you can ship effortlessly 45 versions of app.
This five weeks cycle, that really worked great for us.
And we have that respect in every five cycles.
And we see it's a sweet spot.
Because every retrospection we had,
it took us between 50 and 65 minutes.
And we always have four or five improvements.
And before we used to have that session
that took two or three hours and we had 15 improvements to implement.
It was like, "Whoa, too much."
That's the thing.
We forgot that we have to be more agile.
And actually, it's fun to be agile.
It's fun to improve things, and things are happening in the background.
Things are happening automatically.
It's funny that in our small team,
this whole concept of improving the process, which sounds really boring, is fun.
We actually didn't touch the "horizon expanding month" concept,
but I think that's the topic for another episode in the future.
Yeah, because Radek is constantly fighting that we have a constant effort, appetite available for
improving this process. Because when we stop improving, we stop just
ship, when we switch to just shipping, shipping, shipping, shipping, after a couple
of months we will have the process broken. Because it has to be
maintained to be efficient. Yes, completely. So that's why it's
fun. It is fun to see that and it is fun to be iterating on it. And really
that's why I really again I want to repeat that you know stop every quarter stop and just you know
at least and re-evaluate but also what Rafal said incorporate constant improvements in the process
so like every week basically you get better like every week there is some improvement like just
today we discussed some of the improvements we want to do in this podcast you know um
production process. Every time there is this repeating process, see if there is something
that, you know, some low-hanging fruit as they call it, something that can be quickly fixed,
can be improved, can be automated. And for this, Mighty Flyday is perfect because very often
developers, if they have something that annoys them in the process, like for example a CI machine
that prepares builds is kind of broken or inefficient in some way. They fix it on mighty
flyday.
Yeah, we just bought a Mac Mini. Speaking of getting back to the gear and the geeky
stuff, we bought a Mac Mini, M1 Mac Mini as our Mac server for our CI and for our developer
needs and it's glorious. It works very well and it improved the build times of our apps like
three, four times fold. So this way, when they do something to fix, very quickly there is a build,
there is a new app and we can test the new version right away. So again, these short improvements of
time that you don't have to wait half an hour for the new build to ship, but 10 minutes instead,
It's fantastic. Yeah, and it's very important because we want to introduce like native desktop
apps like for Windows and Mac and it would add a time for the build server to build those every time
there is new change. Yeah, so. Spoiler alert, I'm already using the Mac app on my Mac. It still
needs some tweaking and some working so Radek is on it but it's very promising so stay tuned.
I can't wait for 2022 because we have many exciting things to work on and to ship.
On all fronts, really. On the product front, on the marketing front, on the business front,
lots of good things. I teased some announcements, which we haven't done in December, and I decided
not to do them.
So just for all our users, stay tuned.
We will have smaller announcements in January
and then a big announcement in the beginning of February
as we celebrate our 15th anniversary,
15 years of Nozbe in business.
So there will be cool things in the pipeline, really.
Next year is going to be something.
Really can't wait.
I think it's time to wrap up this episode. We will talk about my iPad Mini next time.
I will gather more thoughts, so don't worry.
Alright, thanks for listening guys and remember, tomorrow what day is it, Michael?
It's Friday and it's a mighty Friday.
Yeah, so remember to do your weekly review, plan priorities for next week and
learn something new or improve something in the process that you are in your work through. That
way you will have a great weekend and great next week because on Monday you can jump on
to your priority list and start getting things done. If you enjoyed this episode please feel
free to help support this podcast either by sharing it with a friend or checking out our
Nozbe Teams app. So I think that's it for today. Say goodbye, Michael. So just
house cleaning before we wrap it up. In two weeks we will not see you, so
Merry Christmas. We are taking a Christmas break, so we will see you in
four weeks. We are taking a Christmas break and I think everyone deserves it,
so Merry Christmas to everyone. Thank you so much for tuning in, for being part of
this show for making this show constantly reaching more people. So we are very, very grateful.
Thank you so much. And if you could rate us on iTunes in the meantime, because you have some more
time, it would be fantastic. So see you in four weeks at the beginning of exactly, we will be
recording on the January 13th, which is my daughter's birthday. And then we will ship on the January 14th.
and until then, you know, make your new plans, plan your new year, use Nozbe to do it,
and make the 2022 your best year ever.
This episode has not been created in the office because in Nozbe there is no workpiece.
Your hosts were Michael Sliwinski and Rafalso Bolewski.
all the links and show notes you can find on nooffice.fm/32.
The whole production process of this episode has been coordinated in a project in a Nozbe Teams app.
Control is good, but trust, transparency and asynchronous communication are so much better.
Thank you and see you in 4 weeks.
remember to have a mighty fly day, merry Christmas and a happy new year.
[Music]