I think there have been equal amount of great products built by average teams and average products build by outstanding teams. I do believe that there is a lot of serendipity in building a great product.
There’s a lot of serendipity in building a great product.
I find a healthy amount of respectful disagreement to be one of the key features of a great team. Being able to challenge each other ideas is extremely valuable and helps to weed out mediocre ideas.
I also noticed that teams which do not obsess with roles and titles and do not fear to pick up tasks from other domains if that’s the right thing to do at the moment produce much more solid result.
And fun of course. Having a good laugh even in the most stressful situations is very important.
SOOOOOO many things!
Design thinking is the silver bullet for all sorts of products and teams.
In my experience, it often ends up being quite prescriptive and limits the possibility for exploration and for actually thinking out of the box. I also feel like at times design thinking is used to cover the lack of craft and expertise — we (as product team) just hand off the solution design to the user under the flag of empathy, instead of actually doing our homework thoroughly.
If the extra effort goes completely unnoticed, or if the change in the metric you are targeting is disproportionally low compared to the invested effort — it is probably a good time to stop.
You now work in tech, but digital products are a relatively new thing. What would you do, had you been born 50 years earlier?
I’d probably either be a flight attendant or work in entertainment industry. Someone would need to coordinate all those disco folks to get the Saturday night fever going.
Bookmate, Notion, Trello, Toggl, Komoot, iNaturalist and Headspace and all the communication apps are the standard. I download a few apps a week — currently I am obsessed with mindfulness and wellness apps. My favourite of the last weeks is Welltory. They are using the phone flashlight to measure your heart rate variability — not sure I trust the accuracy of it entirely, but I found the solution itself to be super neat!
It’s a tough one. I have a few favourite products that I do not use, but love the idea — LabTwin and OneSoil to name a couple. Frankly, I do not think they will ever become mainstream, because they are focusing on very specific problems (scientific research and farming respectively). None the less, I watch them closely and cheer for them because their aspiration resonates with me, I like the teams behind these products, and the way they communicate their values and products is just inspiring to me.
Physical kanban board beats Jira any time ;) on a more serious note, Trello gives more flexibility and incorporates issue-specific knowledge management quite well. I love using it for my own projects, sadly it never took off with any development team I worked with.
Unpopular opinion: I actually don’t hate Jira. It takes a moment or two to set it up well, but I made good experiences with it managing 3 products in parallel, and I value the possibility to connect an issue to related knowledge fairly easily.
Many products that do one thing really well — focus is the key to excellence.
Where are you on the scale from “Deploy early and often” to “Only deploy when you are 100% sure there are no new bugs”?
Early and often on staging, much more careful on production.
I have been mostly working with B2B products and internal software solutions, and one thing I’ve learned is that users that are forced to use your product are a very unforgiving audience.
It is terrible. I recently listened to Jonathan Blow’s talk from DevGAMM 2019, where among other things he talks about recording all the software bugs and issues he experienced in a day. Bottom line: we do not even expect software to work any more.
We are so used to it, that we do not notice it in day-to-day app usage, but when you think how much of our life depends on the software — it just becomes really scary.
We do not even expect software to work any more.
At DV (BCG Digital Ventures), engineering teams put a lot of emphasis on quality as a part of the development workflow, through processes like peer reviews and marinating a certain level of test coverage in code.
We also encourage the teams to use the products they are working on frequently to spot unobvious issues, and we host regular bug-bashing sessions before major releases.
So far I did not have too many opportunities to work with QA. So in most cases I do testing for the functional requirements while engineering team takes care of non-functional requirements.
Enough detail for developer to get a few ideas what might be the problem makes a great report. Be it screenshots, console messages, or video recordings, the idea is to not have developer to spend extra time figuring out what the problem is, but focus on investigating why it occurs and how to fix it.
On fixing technical debt and making the product stable and secure.
Create your free account to unlock your custom reading experience.