I have been writing code and building products more than 15 years now. I have been lucky enough to start my career just around the twilight of Internet, TDD, Extreme Programming and finally Agile. I have had a chance to work in so many different product team sizes and captured so many different aspects of success and failure in my career. Recently, I started to think about things around Product Development and Agile deeply especially in the era of Product vs Service company discussions. In this article, I’m aiming to share my perspective on the topic of Product Teams and Product Development purely from my experience, observations and background.

Before starting to layout my opinions, I need to highlight that I haven’t worked as a Product Manager or wasn’t included in any part of official product management lifecycles. I have been always on the other side of the table where Engineering is the common term in latest startup buzzword dictionary. So, if I feel awkward or incompetent in some areas of Product Management with my expressions, you would need to except these preconditions in order to reduce the annoyance level. These opinions and assertions could be applied or justified at founder level in smaller organisations as well. At least, if you are reading this as a product person, you would take all of these as “user feedback” and “ignore”. Isn’t this how usually happens?

As title suggests, I have concluded the signs I have repatedly saw in product organisations througout my career to 10. The number could be less or more depending on level of annoyance, frustration and maybe with more experience. At the end of the day, these are my own experiences hard won in these years and I fully respect the disagreement this would create in the space. Actually, regarding the audience I’m able to reach on these pieces, it is not even a drop in the ocean…

My list is all about the followings after all:

  1. Product Manager to Developer Ratio
  2. Tester to Developer Ratio
  3. Designer to Developer Ratio
  4. Backlog to Sprint Ratio
  5. Long Release Cycles
  6. No Iteration Frequency
  7. Sales Driven Feature Injection Ratio
  8. Lack of Definition of Done
  9. Lack of Understanding of Technology
  10. Ever Changing Roadmap without Delivering It

I’ll now try to explain them as delibrately as possible but if you really have more questions, you would prefer to contact me. I’m happy to have a chat or coffee even further if I really grabbed your attention in the name of creating a value to your thinking or perception of Product Development.

1. Product Manager to Developer Ratio

Do you really have a Product Manager to more than 5 developers? If your answer is yes, your PM (in short for Product Manager) will suffer to float above the water. PM will get overwhelmed by the admin work needs to be done in JIRA (I assume you don’t use other software because your of boringness). Not only this but also your PM will become or at least look like super lazy and unproductive. The stories will become more of a Task List or one liner in the title. Developers will not get the sense of producing value and will usually lack enough work to finish in a Sprint or will be always overloaded by the vagueness of the stories. In return, it will become super boring to work in this environment due to on going tennis match between tester and developer to close a ticket!

2. Tester to Developer Ratio

Do you really have a Tester to more than 5 developers? If your answer is yes, your Tester will suffer to get things done. There will be constant context switch and there will be no time to automate certain testing criterias. Because your PM is overwhelmingly busy and not producing any Acceptance Criteria during planning phase, your Tester will be not productive at all. It will become almost like a chore to test things again and again due to not having time to automate things. Regressions will not go away and tickets will take longer to close. It will become super boring to work in this environment due to not feeling any quality in what team release, or if they can release!

3. Designer to Developer Ratio

Do you really have a Designer to more than 5 developers? If your answer is yes, your Designer will suffer to spend time in details and will usually drop some PNG manupulations using name-your-buzzy-design-tool in front of developers. Usually, frontend developers will start immediate suffering and frustration. Backend developers would join as well due to random flow changes in vague designs which affects the endpoint designs (hey, everything is Restified, isn’t it?). The data storage will turn into mess due to changing schemas and query plans. Designer will also start feeling super down as everyone rejects or fights back on vagueness. Although, Designer wants to spend time on user research, guerrilla testing, A/B testing, there will be always no time for this except sending all the things in layer1, copy of layer1, copy of copy of layer1, n copy of layer 1 formatted Sketch files.

4. Backlog to Sprint Ratio

Although all these are happening in individual levels, the Backlog, the eye of the tiger, will start to dry. There will be only some stories 2 sprints worth at the quality of PMs time invested and team’s planning time invested. Also, it will become a regularity to ask more stories in the middle of a Sprint. Developers will be assigned to random Spikes that PM thinks off while chatting on Slack with no data or marketing backed analysis. Developer will play in the mud and won’t create any value at all. There will be always super ambitious reports and roadmap plans, there will be always high talks about what can be achieved in Year X while previous years’ goals missed. In the shadow of these, although founders or customers expect to have a great product, although everyone feel about so many things to do, there won’t be a backlog to deliver. It will feel like walking in high street to shop without your wallet. You want to do so many things but you don’t have a backlog to achieve.

5. Long Release Cycles

As a side effect or should I say as an inevitable result, product release cycles will exceed the promises. Even the team is playing by the book of Agile and never miss any ceramonies, still it is not saving the day. Customers and business owners (investors, founders, loyal users) will become less patient while there is always an excuse in the release notes. (Of course these are internal notes). The marketing team will put all the unicorns and rainbows in blog posts to make it feel like happy days after “hard” work. However, team or certain people in the team will not feel proud of what has been produced. The classic dilemma will kick in and Product Management will report how many more developers, technical writers, data scientists and some other cool but not really useful technology developers are needed. Budgets will be adjusted and board meetings will be invaded with even fancier diagrams. Now everyone believes the team is bigger, the machine is bigger, so everything will become faster and better. Of course, this is not going to happen and boringness levels will keep increasing due to issues I listed here overall. The down side of not releasing something after completing development (was it 3 months ago or 7 months ago?) will create lack of ownership and joy on what you produce. This is why certain team members will get even more sick with all this drama played in front of Internet… They may start answering Linkedin messages from recruiters and even may go to interviews… (Has someone coined the retentation rate term in this startup yet?)

6. No Iteration Frequency

Some of the conscious team members will start to look at what has been released and will try to analyse what can be improved. The PM will start to listen these improvement ideas and will happily put it in backlog. Why not? It is already a desert of JIRA tasks. Some very high level vague design and planning will be applied and developer will be assigned to the story. When things are getting deeper and when developer realises the improvement is actually to fix the fundemental design issues and the need for rewrite, the iteration and improvements will start to be tagged “after X”. They will be pushed back to bottom of Backlog to give way on “new roadmap items”. In the end, it will become super frustrating just because all you produce is new random disconnected features and low value, low effort pieces of software released in every 3-4 months with less than 10% adoption rate. (Numbers are random and could be replaced with your real numbers).

7. Sales Driven Feature Injection Ratio

The team will start to design and think deeply on upcoming fancy and maybe less boring features in the hope of this time it will be different mantra. Just in the middle of a Sprint, a high profile Sales team member will convience poor Product Management to push something super low value and super effort to running Sprint. Yes not even on top of Backlog but to running Sprint! Team will try to push back but no luck! Sales team are pressing really high with numbers, ROIs, strategic importance of the “prospect”. The poor Product Manager in the middle of it will also get influenced by the fame of the new prospect. Because the poor Product Manager has been to their office and liked them a lot. Maybe even this new prospect would improve the end of year bonuses because KPIs are designed to behave like that. The team will immediately get frustrated. However, your typical PM answer to all these will be “I hear you!”. It will increase the question of working in a product team over a professional service team formation. The increased ratio of build/not release/forget type of injections will get certain team members disconnect and the reality of the unbreakable loop will feel like Business as Usual! (Oh, I forgot, Sales team also said, we are agile, aren’t we?)

8. Lack of Definition of Done

While all of these are happening, the definition of done will always be a blurry line between a deployment and moving a ticket to Done. Sometimes, moving so many tickets to Done will feel really well. It will also look so cool on board meeting reports and weekly team updates. However, especially developers will not get any attachment to this. All they do is creating Pull Requests, agreeing with tester on which bugs to skip and forgetting what has been done while moving on to next “Task” in the dashboard. (All JIRA things.)

9. Lack of Understanding of Technology

Product Managers are generally good people understanding the technology. However, your boring startup will not have the right investment in people so that really low profile Product Managers will run the show without really putting effort to understand the technology being produced. Most of the time, they will enjoy hanging around with frontend developers because what they achieve together is easy to brag about and usually fun to play. Backend developers, testers and even designers will be always in the room but when they talk and point out things, they will usually find their beloved Product Manager typing something on Slack or checking notifications on mobile. Some stories will be with no description as Product Manager believes the Backend developer knows what needs to be done and tester usually don’t even get the ticket to test as things are not “easy” to test or shall I say not “easy to understand”.

10. Ever Changing Roadmap without Delivering It

Yes, your roadmap is changing every quarter not because you have found a new market opportunity or new evidence to create value from existing production data, but because your best-mate founder thought something while travelling, but because a meetup your Product Manager randomly attended discussed a cool new feature, but because your Product Manager never knows to say No. Team will never feel working towards a goal as it always moves forward. The backlog will always look messy although the board meeting decks are super shiny and tidy up. Late nights are spent for a 540mb slide show of unrealistic promises…

To sum up, by running these questions, it won’t be hard to understand what is going wrong in your startup. I think each topic is its own can be a blog post but this piece is mainly laying out the facts.

However, I believe you will find at least 4-5 things in your current startup at some extend of this. If you are hitting more than 7, your employee retention rate will most probably be around 60%-70%. If you are hitting all of them then you are just burning investor money until your how-I-failed-while-building-my-startup medium.com post. if none of these are happening in your startup, please share me your secret souce. I’ll pour into my team’s next sprint planning and make them grow 10x!

PS: You can call this Canga’s Boring Startup Index and I don’t mind if you popularise it at all!