Layer 1@3x-8.png Product sprint - 3 Lessons learned

About a month ago, we were very excited with the development of a new interface for Attentive, where you can create intelligence lists of companies for to get insights when they get investment, have an important HR change or launch a new product.

Granted, we knew we didn’t have any proper design skills in-house, but we thought we could get away with it. At the end of the day, we were the ones with a vision for the prdouct, so who would materialize that vision better than us?

 After our initial design, we showed to a couple of friends and partners, and we realized that we couldn’t be sloppy in such an important part of our company.

So we got proper design help. Like, professional, experienced design help.

We decided to take a step back, throw away our “in-house design” and started again with the designer - João from Scytale - the amazing studio which we're fortunate to share offices with. (Well, literally speaking, I guess the design  was actually made in-house!)

So we went from a no-onboarding, dull and amateurish looking website:


To this:




Lesson #1 - if you’re not a designer, you can’t get away with your design skills

Actually, you can - for a landing page and blog. For your core product, there is so much work on User Experience, testing, positioning, clarity of message, that makes it really hard to do it on your own.

Surely there are bound to exist exceptions, but in our case, we felt that we should have done it long ago.


Lesson #2 - Bring experts to the sprint

Despite us being a team of 4 currently, we had 8 people actively contributing to our sprint throughout the week. The additional resources allowed to have a fresh perspective on our product, and we could also test many details of the user experience.

How do you recruit these experts? Well, if you’re in an incubator or share offices (like we do), just have another startup help you on your sprint, and vice versa!


Lesson #3 - Have a goal (or two, but make sure you’re progress is accountable)

It’s incredibly easy to start with a huge list of things you have to do, but when you start a sprint, you either have a very clear deliverable or a very clear hypothesis to test. If you spend the first 1-2 hours of the sprint deciding on objectives, it’ll be much easier to ignore the new bugs and good ideas that will appear and just focus on delivering the goal. Log the ideas and bugs and leave them for later!


The structure we used for the sprint was inspired by the Sprint Book. We feel that as you repeat the structure the whole team gets better at understanding how everyone can contribute to achieve a tough problem that affects the whole company. 


What about the outcome of the sprint?

Our main objective was to design, prototype and test the new interface with users. We were able to design the core prototype, and we are implementing it this week.


In two weeks, you can also test this new version, just let us know and we’ll add it to our closed beta program. The program will be available in co-horts, so the sooner you let us know of your interest, the sooner you’ll have access to it :)


Get access our Private Beta



Recent Posts