Hey there. You may have been reading my previous posts about what we’re up to at Knotch. Why we’re here, what the market needs and what problem we’re here to solve. Today I wanted to give you a lens into how we’re building our product.

Here’s my experience after almost a year working at the company. We’ve gone through a product pivot, a bit of a PR storm, being named one of the top 50 marketing startups at Cannes and signed up our first clients as we gear up towards our big launch in NYC in September.

Three months ago, I went from managing marketing and sales to managing our product. For someone who's had a career as a theatre producer and saw software engineers as superheroes capable of performing magic through their fingertips, this was a rather terrifying prospect. 

On May 21st, I flew to San Francisco, armed with a mentor, and said hello to words like API, web, refactoring, render and DB. I learned the difference between dev and production (to theatre folks: roughly like 'rehearsal' and 'production'), Jira and Trello. I also found out that a sprint is nothing to do with actual running, and that Java is not a cuter version of Javascript.  

Here’s what I’ve learned so far from our excellent engineers, our head of product, CMO and CEO.



Are you building the right features at the right time? A product manager’s job is not necessarily to know how things get built, but what and when needs to happen in the product development. The theatre producer in me has concluded that engineers are a lot like artists. You need to set them up with a brief, a framework, timelines and then leave them to it to figure out the how.

Trust, but check. Management is no easy task when you’re dropped into a new team. I freely admit. I was so eager to learn everything as soon as I started that I probably startled, distracted or confused every engineer. But in the same way that you learn to optimise a lot of things in life, you learn to optimise your management too - to fit moments of crisis, to meet deadlines and to check on progress. 


·       Almost daily one-on-one check-ins with engineers to see how they’re doing and get status updates from different angles

·       Appoint an engineer to oversee an issue being solved in crisis mode

·       Get to know them as people. I followed our engineers home to walk their dog, grabbed beers with them or cheered them at their gigs. You need to learn what motivates and annoys them as people.


Don’t assume you’ll make a great manager. You’re in a new team with certain dynamics and you need to walk carefully, and seep into the lives of others. I’ve gone from being too hands off and trusting to a total micromanager after a crisis point. It was as if I was on a different management medication every week.  

I’m learning to define my path somewhere in the middle. Navigating a team with your engineers’ feedback, leadership and humility is a skill I’m learning to iterate as much as we iterate our product with regular client feedback. 


·       Learn to ask smart questions. Seriously, research questions that will help your engineers find solutions or clarify for you the actions they want to take.  

·       Admit to your mistakes as soon as you realise them, and say what you’ll do next time instead.



Knotch has multiple offices. Each employee can move flexibly across the world as long as we get our work done. I’m the loose cannon currently in Europe, so staying accountable is a pretty key thing. Being responsible for your own workload is not even a rule. It’s more like a religion.  

On a company level, we have a Google-adopted system (OKRs), which means we set company goals 2 weeks ahead. Each person on the team then breaks down those goals according to their role. Product-wise, this is when we start a new sprint with new features to build or specific issues to solve.

We have a weekly meeting to check on the progress half-way through. After two weeks, we ‘green’ what has been achieved and set ourselves new two-week goals.

Being accountable to each other, and sticking to the promise of what to get done is very powerful. It develops independence and loyalty, but also a sense that crap work simply isn’t allowed - it’s a bit unfair on everyone else’s work and efforts.


·       Do your daily standup with engineers - what everyone did yesterday and what they’re planning on achieving today. It can also be useful to set a day goal.

·       Show what’s being done - using Trello to help us manage tasks also means that we know what we’re currently working on and what the issues are, as they’re described in the task card and clarifications happen within them.

·       Ban the word ‘ALMOST’. Everyone’s idea of ‘almost’ is skewed. Make sure your engineers give you an ETA on when features can be shipped. If they can’t, allow them some time to figure out an ETA first. It can also be a sign that it’s too big a task and needs to be broken down into more manageable chunks first.

 Sprints live in Trello at Knotch. 

Sprints live in Trello at Knotch. 


This brings me to my favourite subject. Yep, tools are insanely helpful. Because we are often distributed and remote (especially now in the summer season), keeping in touch and getting work done efficiently is key. What tools do we use and what are they useful for?



  • posting updates in channels you customise (we have #standup, #engineering, #general, #status, #random & #useful)

  • one on one chatting

  • saving notes and links (thanks slackbot)

  • integrations with other tools - mainly useful for engineering

  • the search button!!!

  • GIPHY (this is actually key for happiness levels)  
 God bless Giphy. 

God bless Giphy. 


  • keeping on top of what is currently being built per sprint by creating task cards

  • knowing what each engineer is currently working on (we have 4 columns - TO DO, IN PROGRESS, TESTING & DONE)

  • discussing issues that come up within each task card

  • integrated in our #status channel



  • keeping track of issues and bugs that need resolving according to levels of importance

  • remembering and storing what possible issues we may need to solve in the future

  • having an archived list of all past issues, their details and assignees.

  • integrated in our #status channel


  • excellent for templates for managing sprints

  • creation of Epics (user stories to solve) and linking JIRA issues to them

  • documentation and storing customer feedback



  • sharing and editing any type of documents with the team

  • keeping on top of our product roadmap, sales pipeline and company OKRs

  • integrates with Slack!



  • notifies engineers about errors so that they can fix bugs quickly

  • integrated in our #status channel



  • for knowing when things get deployed

  • integrated in our #status channel



  • what should I say, no remote meeting or client call would be possible without it

  • consider getting yourself an amplifier to make sure your remote team members can be heard when you have an in person meeting (nice one Erik).


As I’ve learned in my short life span as product manager. You can never do enough testing. I now test the product for quantitative values every day and make sure there’s no bugs - or I catch them early enough - in the current product.

We’ve also created a rule that anyone on the engineering who does a deploy (pushes something into production) needs to be responsible for testing. Testing new features at the end of sprints is done by our appointed test master engineer (hey Devin), who’s our safety blanket and also creates instructions on how to test. He’s also brilliantly automated as much of the process as possible to save time.


  • Make testing part of your morning routine. (You know, coffee, yoga, testing, that kind of thing.)

  • Test the accuracy of time values by using automated testing - we used Nightwatch.js that uses Selenium

 Nightwatch.js allows you to test time values. 

Nightwatch.js allows you to test time values. 


Talk to clients after they’ve used your product for a while. Ask open-ended questions around what’s valuable, ask targeted questions about features you’re not sure about. Drill down on why they need particular features or have particular needs.

Set up trusted testers. We’ve created a signup system to a beta that allows our potential users to leave their email address and tick if they’re from a brand, agency, publisher or other. This gives us a really good sense of who to turn to for testing purposes.

I’m currently working with a few testers who I will interview next week - with the same questions that we turned to our current clients with. We don’t have a public trial for testing Knotch. By keeping it a little hush-hush, it means that when potential users do get access via a testing selection, they’re much more receptive and eager to go ahead with testing and giving feedback.



  • Write a list of things you know (for a fact) and don’t know about your product and construct your questions around them.

  • Keep all feedback in one simple spreadsheet; this will help you spot themes and validate what you should be working on and solving next. (All credits for this tip go to Joel, thanks mate!)


Research your competition. Research trends. Research your customer needs. Research features. Research technical requirements. Research and learn about code. Research what your target clients are doing right and what they’re doing wrong. Research which clients are your specific target and how you can make their lives better. Make sense of it in the context of your sprints’ themes and company OKRs.


  • Keep on top of your social media accounts (especially twitter) to search for news in your space, keep an eye on competition and start conversations.  

  • Involve people you admire and their points of view in your blog posts to help you start a conversation with them.


There will be tons of feedback, links and information to process. Don’t let it get lost. If you're someone who naturally enjoys organising things, writing to do lists and coloured post-its, you'll love product management. If you don't, well, then you might have a tough time. 



  • Make sure every bug or issue is added to Jira as soon as it occurs

  • Don’t let anyone work on a new task before they’ve created a Trello card

  • Update your product roadmap with what has been achieved every week  

  • Save links in Slackbot (lets you save notes just for you to see in Slack) and give them easily searchable titles/ tags.


For a while I thought my job was to create a cool and ambitious sprint plan and check on engineers about how they’re getting on. It’s that, sure, but being a product manager is a role that sits at the intersection of product, business, user experience and marketing. You also need to be a human being with the eagerness to create the best engineering team.

You’re not only responsible for shipping product, but shipping the right and most valuable product for the right kind of customer and at the right time. Your job is to maximise the value of what your company is selling, while also making the life of Head of Product, CEO and CMO more manageable.

 Image via Mind The Product. 

Image via Mind The Product. 

How have you become a product manager? I’d love your thoughts on how you’ve built your products. Any tips I've missed and anything else you'd like to know about? 

Get in touch and let’s chat.